Skip to main content
newbeea
Associate
April 17, 2024
Question

usage fault occored at STL_SCH_RunFlashTM()

  • April 17, 2024
  • 1 reply
  • 2003 views

rtos: zephyr

MCU: STM32H723VET6

Package: en.x-cube-classb-h7 v4.0.0

I‘m working on make my program running on H7 to meet the requirements of Class B.
The CPU and RAM test works well both on startup and run-time. I haven't prepared the CRC precalculated area and only want to see the Flash test failure, but the Flash test stuck at STL_SCH_RunFlashTM(). 

From CubeIDE I can get the stake message as belows. But I have no idea how to prevent it from fault.

 

Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)
z_arm_usage_fault() at fault_s.S:80 0x802e808
<signal handler called>() at 0xfffffffd
VerifyAllSections() at 0x8021b38
STL_TM_FLASH_RunTM() at 0x8021aa2
STL_SCH_RunFlashTM() at 0x8020d9e
STL_RunFullTest() at classb_st.c:188 0x8027ce4
stl_classb_init() at classb_st.c:438 0x8027d80
z_sys_init_run_level() at init.c:247 0x8037394
z_cstart() at init.c:528 0x8037506
0x31538a
 
and the final core registers value are:
newbeea_0-1713333962367.png

 

my source is totolly the same as the sample.
newbeea_2-1713334424024.png
newbeea_1-1713334208273.png

 

 

This topic has been closed for replies.

1 reply

Petr Sladecek
Petr Sladecek
ST Employee
April 18, 2024

Hello,

there are many factors to be checked. Initially, what is output reported by the failing module (STL_ERROR/FAILED/KO)? Is the run module properly initialized and configured in advance? What is the subset configured during the failing test? Does it go outside the binary area? Note CRC are computed for sections occupied by code exclusively!

Is the binary area to test defined at the subset fully contiguous without any gaps in between the linked sections of code? I suggest to check this by build analyzer window or linker map file. Does it start at begin of 1KB section and it is word/32-bit aligned at the end? If the area is not continuous, does it help to program the code by STM32CubeProgrammer? Note debugger downloader can fill the gaps by different values then those assumed as default applied by the Programmer during the CRC calculation.

Does the post build command invoking the CRC calculation match with the tested binary and its allocation? Does it fit inside the physical flash area of the product (note CRCs are stored at the end of the area defined by the command). Are the CRC checksum field truly present at the memory there? Check it by the memory dump.

I suggest to start with single section test initially starting from area begin while apply atomic step of the test set to 1 (~ test first 1KB of the code), check the module output, and increase the number of steps one by one to see when error happen.

Best regards,

Petr

    Terms & ConditionsAccessibility statement