S32K312 Secureboot and Program Flash The attached CMM file is a script that writes the FBL and App to the S32K312 MCU and then activates SecureBoot, SecureDebug, and Configuration Lock. We would like to request a review and improvement regarding the HardFault issue that occurs when running this CMM. Previously, as shown in the screenshot, a HardFault occurred after the FBL and App were imported when executing "Go," with the JTAG Clock set to 5 MHz throughout. As a change, we set SYStem.JtagClock to 1 MHz after importing the App file. With this change, HardFaults rarely occurred at the "Go" step when running the CMM, so we concluded that lowering the JTAG Clock speed is an effective approach. However, when the modified CMM is applied, a "stopped by vectbl" error occasionally occurs at "Go" after the FBL and App have been imported. We kindly ask you to review the CMM so that it can run stably overall, and we would like to inquire about how to improve it so that the "stopped by vectbl" error does not appear at all. Original CMM: GN7_PE_MAIN_G_SECURE_260412.cmm Modified CMM (JTAG Clock changed to 1 MHz): GN7_PE_MAIN_G_SECURE_260412_0714RE.cmm Additionally, we would like to import a different FBL after SecureBoot has been enabled. Is there a way to import a different FBL while SecureBoot is enabled? If it is possible, we would appreciate it if you could provide a guide. Re: S32K312 Secureboot and Program Flash Hi @jeongwoo
The main problem I can see is this:
This means: you load the pink file and you reset the device. After this reset, SBAF is supposed to install HSE firmware. But the key point is - this operation takes about 1 second. But then you reset the MCU again in 0.1s and you are going to reprogram pink file at 0x40_0000 by fbl immediately after that. Increase the waiting time to 1.3s, at least. Otherwise SBAF tries to install HSE FW and you try to reprogram fbl at the same time.
Regards,
Lukas
Re: S32K312 Secureboot and Program Flash Hello, thank you for your reply. Regarding the part where the delay time is currently set to 0.1 seconds after adding HSE, there are no issues with the program functions written to the controller even when the time is set shorter. I would like to ask if it is absolutely necessary to increase the delay time to 1 second. Re: S32K312 Secureboot and Program Flash Did you tested this with a device where HSE firmware is not installed yet? I don’t think this can work. The installation takes little bit more than 1 second. If you cut the installation by reset after 0.1s and if you erase the pink file right after that, SBAF can’t install the firmware. Re: S32K312 Secureboot and Program Flash Hello, First, I confirmed that when writing with the CMM configured with the existing 0.1-second setting, a hardfault appears in Trace32, but there is no impact on the firmware functionality. It appears that the FBL and APP executed normally. Is there perhaps a register address value that can be used to check whether SBAF or HSE is operating normally? Additionally, regarding the CMM that accounts for the HSE application time you mentioned, "stopped by vectbl" did not appear during execution. However, I confirmed that "stopped by vectbl" is still displayed even when changing "wait 3s" to "wait 2s" after FLASH.ReProgram ALL during APP Import. Could reducing the APP import time also have an impact on this? Re: S32K312 Secureboot and Program Flash Hi @jeongwoo
I think I may have found a potential issue in the script.
After loading fbl_m4, the bootloader is started using the Go command. The script then enters a loop where it periodically reads the Boot Configuration Word and waits for the value 0x9. This means the script is waiting for the bootloader to initialize Secure Boot and update the BOOT_SEQ bit in the Boot Configuration Word. However, performing this update requires the bootloader to erase and reprogram the entire flash sector, which can take quite significant amount of time.
During that period, the debugger repeatedly reads the same flash location. This may lead to a Read-While-Write conflict. While a flash block is being erased or programmed, it generally cannot be read at the same time. As a result, the debugger may encounter an access error, which could explain the observed behavior.
A cleaner solution would be to use a status variable located in RAM instead of polling a value stored in flash. Once the bootloader has completed all Secure Boot configuration steps, it could update a dedicated RAM variable. The debugger could then periodically read this RAM location. Since RAM accesses do not interfere with flash erase/program operations, this approach avoids any potential Read-While-Write issue.
I also noticed that the same method is used multiple times throughout the script, so I would recommend reviewing and updating all similar status checks, not just this particular one.
Regarding HSE status:
To determine whether the HSE firmware is installed, check bit 0 of the HSE GPR register at address 0x4039C028. If this bit is 1, the HSE firmware is present.
To determine whether the HSE firmware has completed initialization and is ready to accept requests, check the HSE_STATUS_INIT_OK flag (bit 24) in the MU0 FSR register. Once this bit is set, HSE initialization is complete and services can be used.
查看全文
