Issues with Enabling Both Flash Security (FSEC=0xBF) and CSEc Simultaneously

[xyzhang]

Regarding the use of FS32K146HAT0MLLR, I encountered the following issues:

During usage, I need to simultaneously enable CSEc and Flash Security (FSEC=0xBF). However, even after enabling mass erase, I am unable to perform operations.

            1.If I want to re-enable the debug port, how should I proceed?

            2.If I need to recover the partition, what steps should I follow?

Could you provide detailed instructions to achieve these operations?

I would greatly appreciate your prompt reply.

[lukaszadrapa]

Hi @xyzhang 

This was discussed here many times. For example here:

https://community.nxp.com/t5/S32K/Erased-whole-flash-of-the-S32K144/m-p/2039129/highlight/true#M4567...

If CSEc is enabled, mass erase is blocked. 

To make the debugging/development/tests easier, my recommendation is to implement following functionality to your application: when some push button is pressed or when certain command is received via UART/CAN, either reprogram FSEC to unsecure state 0xFE or run CMD_DBG_CHAL+CMD_DBG_AUTH commands. Or do both operations. So, you will be able to recover and start over. 

Or implement backdoor access, so you will be able to connect the debugger, at least:

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K144-Verify-Backdoor-Access-Key-S32DS1-3...

But if nothing like this is implemented and the device is secured and CSEc is enabled - there's no way to recover. 

Regards,

Lukas

[xyzhang]

Thank you very much for your timely reply. I will try again according to the method you provided to achieve the erasing function.
Besides, I encountered another problem during the usage process and need your help. The problem is as follows: I have implemented the functions of CSEc by writing program code, including loading keys, encryption, decryption, etc. And online debugging was carried out through the compiler, and no problems were found. However, when burning the generated.hex document to the target board, the burning is carried out in the following two ways. The first one is to use a compiler to connect to the target board via Cyclone lc for online burning of the.hex document. The second method is to store the generated.hex document in Cyclone lc through Cyclone software, then disconnect from the computer and directly connect to the target board through Cyclone lc to burn the previously stored burning file in the burner offline. The current issue is that the burning can be successful through the first method, and the board can operate normally after being powered on again. However, when using the second method, Cyclone lc shows that the burning was successful, but the board cannot operate normally after being powered on again. Could you please tell me where the problem lies? Could you offer some solutions or ideas to solve this problem? I would be very grateful for your prompt reply!

[lukaszadrapa]

1. If you read whole flash memory to a file by the Cyclone in both cases, is the flash content exactly the same? 

2. Is content of FCFG1 register in SIM module the same in both cases?

[xyzhang]

Thank you for your prompt reply.

1.In both cases, the flash contents are completely identical.

2.In the SIM module, the DEPART field of the FCFG1 register is 0x3, and the EEERAMSIZE content is 0x2. These are the expected values.
Additionally, I have set the FSEC value in the startup file's Flash configuration to 0xBF. Could this be causing the aforementioned issue?

[lukaszadrapa]

Yes, configuring of FSEC could make a difference. The questions is how Pemicro implemented this in their firmware. My colleague told me that he met something similar on S12 devices – it worked with debugger but not with Cyclone in standalone mode. And it was caused by different approach to security byte in flash. But notice that this is Pemicro’s proprietary firmware, so I recommend to check this with them directly:

https://www.pemicro.com/support/index.cfm

Have you implemented Backdoor Key Access to your software? Are you able to connect your debugger to this device? If yes, can you check the content of flash configuration field at 0x400?