Read protection for STM8S/32

1. Preparation:
After the HEX file and JLINK driver (JLinkARM_V420 or above, secure chip may appear gray and unselectable in 4.08) are installed, you can open the application in Start--All Programs--SEGGER--J-Flash ARM
First set the chip to be written and the writing method,
select JATG or SWD
Select the chip model: Option-->Project settings-->CPU-->Device (the program cannot be written if the model is wrong, set Option-->Project settings-->Production, select Securechip;)
2. Open the HEX file to be burned: File--Open data file, you can pull down to select the HEX file type
3. Connect the chip to be written: Target--Connect (before this step, you can clear it first and then read it out to see if it is read out as completely empty, so as to compare it later)
4. Write code: Target--Program & Verify (F6)
(This is the process of writing code, and the following is the step of adding read protection)
5. Add read protection: Target---Secure chip, click Yes, and read protection is added!
2. How to verify whether it is read protected
The verification method is to use a chip without read protection, repeat step 3, connect it, read back, and see if it can be read?
Then use a chip with read protection, repeat step 3, connect it, read back, and see if it really cannot be read. If the read protection is successfully added, it will stay there, and the data cannot be read out, and finally an error warning will pop up!
At this point, the read protection has been loaded!
3. How to remove the read protection for code update
The code needs to be updated. If the read protection function is not removed, it will be difficult to write the program again. The removal method is the reverse operation of item 5 in the step: Target---Unsecure chip
After the removal is successful, you can write your updated code again. There is no need to change the settings of BOOT0 and BOOT1 as netizens say, etc. . .
4. How to write read protection with one click
This step of loading the code read protection function may be troublesome for some people. After all, when there are many products, you have to press the write protection command after writing. For the production line operator, you may forget one of them due to negligence, which will cause the code to leak. Should there be a simpler way to write with one click? The answer is yes! The specific
method is to add a few more steps before generating the HEX file.
1. First, load: an STM32F10xOPT.s file in the C:KeilARMBoardsKeilMCBSTM32Blinky folder
2. Modify the following two values ​​to 1
3. Be sure to perform this configuration before generating the HEX file
Such a simple HEX file will make your product flow into the market. Even if it is copied successfully, the code will not leak, as long as the employees of your company do not leak it.

How to debug STM32 in ram and flash under ulink-Jlink

http://www.21ic.com/app/embed/201209/142684.htmTime
: 2012-09-11 Source: Author:
Keywords: ulink-Jlink   flash   ram   STM      
Keil MDK3.20 Methods for debugging stm32 under ULINK
1. The program runs in RAM
Key points: (1) The download address of the program is changed to the RAM space
(2) Before debugging the program, the SP and PC pointers must be set to the Ram space
a Create a new project and select the specific model of STM32. 
b Set the program download address, as shown in the figure below, the address of IROM1 points to the RAM space of STM32.
c How to allocate the space size depends on your needs. The internal RAM size of this processor is 20K, 16K is allocated to the read-only area, and 4K is allocated to the readable and writable area. In this way, the size of IROM is set to 0x4000, the start of IRAM1 becomes 0X20004000, and the size is only 0X1000.
d Select ULINK1 Cortex Debugger in the Debug tab (the software uses the crack method of yjgyiysbcc). Uncheck Load Application at Start, and add the startup script RAM.ini in Initialization. 
The specific content of RAM.ini is as follows:
FUNC void Setup (void) {
SP = _RDWORD(0x20000000); // Setup Stack Pointer
PC = _RDWORD(0x20000004); // Setup Program Counter
_WDWORD(0xE000ED08, 0x20000000); // Setup Vector Table Offset Register
}
LOAD XXX.axf INCREMENTAL // Download, red represents the project file name.axf
Setup(); // Setup for Running g, uncheck Update Target before Debugging under
main Utilities After adding this, you can debug in RAM. >>>>>>We need to set the correct interrupt vector table location in the code. The interrupt vector table is usually placed at the beginning of the user program, so when running in flash, the vector table is located at 0x08000000, and when the code is placed in SRAM, its location becomes 0x20000000. When initializing NVIC, we can place the following code to define the location of the vector table NVIC_SetVectorTable(0x20000000, 0x0); or NVIC_SetVectorTable(0x08000000, 0x0); or

 
>>>>>In the Debug item in the project options, in the Download tab, remove all hooks, do not download the code to flash, so that you can debug the program in RAM!
2. Debug in Flash
After creating a new project, the system defaults to setting IROM1 as the address and space size of FLASH. Only two steps are required:
1) Set the debugging tool to ULINK1 CORTEX DEBUGGER, as shown in the figure below, and there is no need to set the start script.
 2) Set and select ULINK1 cortex debugger in Utility, and set the programming algorithm. As shown in the figure below.
 After that, you can debug in FLASH.
Hardware: Wanli's EK-STM32F development board, remove RS3, RS4 resistors from the hardware, and disconnect the emulator of the development board itself.
Software: KEIL MDK3.20+ULINK driver replacement file.
Emulator: ULINK

STM8S read protection:

After reading the document, I feel that the protection measures are no different from those of MEGA88.
ATMEL refuses to admit that MEGA88 can be decrypted. However, it is true that for 1,000 yuan, you can get the complete code, and it is disassembled. After compiling, re-burning everything is normal.
How is the confidentiality of STM8S103K3? Are there any indicators to refer to?

First: IC has no backdoor. Many bad IC design companies, especially those in Taiwan, have backdoors. Agents can easily read the ROM code and give it to customers.
Second: Currently, decryption is done by cutting the IC open and reading the contents directly. Many decryption companies do this. It is said that there is a detection mechanism in STM8SXX: when the IC is cut open, the FLASH contents are automatically erased. This is just heard and has not been verified.
 

But from the perspective of chip design, the chip also has many layers like PCB, usually at least ten or twenty layers. We design the parts that need to be kept confidential, such as Flash and Flash lock, at the lower level. In this way, even if the chip is cut open, many layers must be removed before the required layer can be found. Since we don't know which layer the Flash is on, the difficulty of dissection is further increased.
--------------------------------------------------------------------------------
I think ATMEL's MCU is also designed in this way. But it is very easy to be cracked. For
example, Taiwan's MCU does not need to be cut open at all. It can be read out for 500 yuan. ELAN, SONIX, etc. also claim that the IC is encrypted.