The issue of S32K314 secure boot : BSB

[liTian_one]

1. I successfully loaded the secure boot IVT and TAG.srec. After powering off and on again, it was able to run (the CAN diagnostic data was sent with a response).
2. To verify this from another angle, I manually modified the gmac content in TAG.srec and then loaded it along with IVT. However, it couldn't run normally. This should be normal, right?
3. I attempted to re-load the normal TAG.srec, but the loading process failed. It kept showing that the chip was locked and there was no way to unlock it using the script.

4. Attempting to rewrite other routines also results in the same error message.

Could you please tell me what needs to be done to unlock it?

[VaneB]

Hi @liTian_one 

Have you enabled restricted access to the MCU through JTAG? In other words, did you program a password and advance the MCU lifecycle, either using HSE or without it? To unlock the device, please refer to the following link, which provides the necessary steps and scripts to unlock S32K3 devices when secure debug is enabled:

NXP: Using PEmicro Tools to Enable S32K3xx Secure Debug Support

Also, if you are working with a custom board, could you please verify that there are no hardware-related communication issues between the MCU and the debugger? Other customers have reported seeing similar secure debug windows when encountering issues related to JTAG communication or when the SBC is not powering correctly, which could prevent the MCU from being programmed (FS26). 

BR, VaneB

[liTian_one]

Yes, I have program a password and advance the MCU lifecycle, and using HSE.  

I followed the method you provided and performed the PE unlocking operation, and it was successful as indicated. 

However, after that, when I was debugging, the problem still persisted.

Is it the case that "secure boot" and "secure debug" cannot coexist simultaneously?

When secure boot fails, the secure debug cannot maintain the unlocked state?

[liTian_one]

Could I understand it this way? After unlocking, before the debugging and flashing process could be completed, it was automatically returned to the locked state.

[VaneB]

Hi @liTian_one 

Secure boot and secure debug are indeed designed to coexist. As long as the ADK/P (Application Debug Key / Password) is known and debug access is enabled, it is possible to recover the device in the event of a secure boot failure.

If an SMR verification fails during any boot phase—whether pre-boot or post-boot—one of two types of sanctions may be applied. Based on the applicable sanction, the HSE firmware will enter its default recovery mode.

In cases where the device enters JTAG-Based Recovery Mode, the HSE remains in a reset state. This reset condition also clears any active authentication.

[liTian_one]

This sentence means: Does this reset condition clear the unlock authentication of PE?
After a power-on, if I execute the PE unlock script multiple times, does this reset condition clear the multiple unlock authentication of the PE?

[VaneB]

Hi @liTian_one 

Yes, every time a reset or power cycle occurs, the authentication is cleared, and the device returns to its locked state.

This is also why it is necessary to select the "SECUREDEBUG" version of the device in your debug configuration (e.g., "S32K344-SECUREDEBUG" instead of "S32K344"). This selection ensures proper handling during debug entry, especially since a reset is triggered as part of the debug initialization process.

[liTian_one]

Sorry, I didn't express my confusion clearly.

I would like to know: During the BSB secure boot process, if the HSE firmware verification fails, will it cause the PE unlocking operation performed afterwards to become ineffective?

How can I solve the problem that was initially raised?

[VaneB]

Hi @liTian_one 

If the HSE firmware authentication fails during the secure boot process, it may affect any prior authentication done by the debugger. However, you can still reconnect the debugger to recover the device.

In case of a secure boot failure, the SBAF will first attempt Secure Recovery Mode. If that fails, it will switch to JTAG-Based Recovery Mode, where the device waits for a debugger connection to allow recovery.