usage fault occored at STL_SCH_RunFlashTM()

[newbeea]

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:

 

my source is totolly the same as the sample.

 

 

[Petr Sladecek]

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