My program is divided into two parts: boot and app. In boot, the startup file startup_S32K144. S maintains the default configuration, while in app startup file startup_S32K144. S, flashconfig is modified as shown in the following figure. After compiling and burning, I found that jlink can still connect normally and can burn and read programs normally. Why is read protection not effective?
Hi @wangmingming,
Sorry for the late reply. If you refer to S32Kxxx - SEGGER Knowledge Base, if (allow security) option is not selected, J-Link will inhibit that the readout protection of the device is set.
Modify the FSEC register in startup_S32K144.S file and generated a .hex file with S32DS. Then, select allow security in J-Flash, you should be able to secure it:
Best regards,
Julián
Thank you. After following the settings above, the read protection took effect. However, when I tried to read with jlink, it returned a full FF. After restarting, the device did not work. Is it because the full erase is automatically triggered during reading?
Hi @wangmingming,
I'm not sure what you mean by "device did not work", but the security configuration is set only after restarting the device:
Yes, my steps are as follows:
1. Set the flash config to security state and burn it after compilation.
2. The device restarts and can work normally. At this point, I tried to use Jlink read back to read the program of the chip, and the returned data was full FF data
3. The device restarts and does not work at this time. Repeatedly restarting, the device still does not work
My question is, is it normal for the chip program to automatically trigger the entire chip erase when read with protection enabled? Because the situation I discovered here is like this.
It is not normal to trigger a reset upon a read command. Could this be an issue with the SEGGER debugger/SW? You can try securing and reading the S32K144 through S32DS instead. Upon reading, you can see the device is protected (once reset).
If the issue persists with J-Flash, I suggest contacting SEGGER instead.
Best regards,
Julián