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?
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.
Hello Lukas,
Thank you for your reply.
My understanding is that after the bootloader has been uploaded once with its initial value (0x1), it performs another Erase/Write cycle to apply Secure Boot (changing 0x1 → 0x9), and during this process the error appears to occur when the polling method attempts to read that address value.
As you advised, we tried to use a status variable located in RAM. However, we distribute our software as a Hex file. In this case, if we use the address defined in the .map file, the RAM address differs from program to program, making it difficult to unify the writing script. As a result, we concluded that in order to check the Secure Boot, Secure Debug, and Configuration Lock status within the script, we need to use the values defined in the IVT.
Therefore, based on your feedback, instead of applying a 1.5s delay after the HSE upload, we applied a method that checks the HSE_STATUS_INIT_OK flag (bit 24) of the MU0 FSR register. We removed the existing fixed waits (e.g., wait 1.5s, wait 3s), and modified the script so that, after a reset, it polls until that bit is set before proceeding with the flash write (FBL/APP loading). We added this method to every stage following System Reset and Sys.UP. In addition, we plan to change the status-check polling interval for each status from 0.5s to 1.5s. We have also added a wait before the first read after Go. We would greatly appreciate your opinion on whether these timing settings might be insufficient. So far, we have confirmed that writing with this script completes normally without any Fault, and that the device operates correctly when we perform GO after writing.
(We have confirmed that the time it takes for the value at 0x400004 to change from 0x1 to 0x9 is approximately 800ms.)
Regarding the previous issue where a HardFault occurred when the FBL was loaded 0.1s after the HSE was uploaded: when we checked the HSE status values you mentioned, we confirmed that all of them are reported as normal. The program functions also appear to execute correctly. This error (HardFault) appears when we load everything through HSE → FBL → APP and then perform GO. Given this, we would appreciate your opinion on whether it would be advisable to increase the delay time so that GO is executed after writing, as you recommended.
Best regards,
Hello Lukas.
As per the guidance you provided earlier, the image file (.elf) now runs successfully ("Running") without being stopped by vectbl. However, the binary file (.hex) still throws a "stopped by vectbl" error when I perform GO after uploading the app.
This appears to be a symptom where "the App jumps to an invalid address in its execution flow and fails while trying to fetch the instruction at that location." Is there any way to resolve this issue?
Even when the vectbl error occurs, the normal writing appears to complete correctly as originally intended upon POR (Power-On Reset), but I need to confirm whether this error is one that can be safely ignored.
Thank you for your continued support.
Best regards,
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
