BusFault at address 0 for STM32H5xx Arm M33 non-secure non-trust-zone

Kernel
1

I’ve experienced infrequent intermittent hard faults on our project for months but it’s been crippling as we have started turning up the CPU usage and associated context switches.

Does anyone know what M33 port I should have started with for this processor? I am unsure that I have the processor in non-secure mode and my tools are having a hard time digesting the main and process registers so when I get the hard fault I am not properly unwinding the stack(s) to find the offending hard fault instruction.

2

You would start with the NTZ port, for example FreeRTOS-Kernel/portable/GCC/ARM_CM33_NTZ at main · FreeRTOS/FreeRTOS-Kernel · GitHub.

Do you have configASSERT defined?

Do you know which kernel version you are using? Several helpful checks have been added to more recent versions.

3

If you are not using trust zone, then you should use NTZ port as @jefftenney mentioned.

If the tool does not work, you can find out the faulting instruction by reading the registers in the fault handler. Here is an example - FreeRTOS/FreeRTOS/Demo/CORTEX_MPS2_QEMU_IAR_GCC/build/gcc/startup_gcc.c at main · FreeRTOS/FreeRTOS · GitHub.

4

I have reciently update to the tail of the FreeRTOS-Kernel so I’m running 11.1 I think. My config file though is probably two years old from when I started the project.

I am using
set(FREERTOS_ARCH ARM_CM33_NTZ)

from src

set(DRIVER_DIR ${CMAKE_CURRENT_SOURCE_DIR}/…/STM32Cube_FW_H5_V1.0.0RC2/Drivers)
set(FREERTOS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/FreeRTOS)
set(FREERTOS_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/FreeRTOS/)
set(FREERTOS_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/FreeRTOS/include)
set(FREERTOS_ARCH_INCLUDE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libs/FreeRTOS/portable/GCC/${FREERTOS_ARCH}/non_secure)
set(FREERTOS_LIB ${CMAKE_CURRENT_SOURCE_DIR}/libs/FreeRTOS)
set(FREERTOS_CONFIG_DIR ${CMAKE_CURRENT_SOURCE_DIR}/src)

for my build selection…

I do have configAssert mapped to my own assert implementation.

I started the work on a NUCLEO bord for the H5 processor I think two years ago. I’ll compare the config file with a more modern one, we have gone through a couple board revisions since the first FreeRTOS integration.

5

I believe that I am using the NTX and non-secure files.

I have a concern that this may not agree with the processor state. I’ve got a ticket in with ST about it (you guys are much faster). But the documentation around the M33 SAU registers does not jibe with the behavior.

SAU_CTRL defaults on startup to 0x00000000 which is means that the processor is operating in secure mode but when I try to may my whole .text segment a non-secure region the SAU setup registers seem to behave in the RAZ/WI model which the data sheet indicates is teh non-secure mode.

If anyone can tell me how to get the processor (and ideally verify) in non-secure mode I’d love a simple command or sequence that I can follow.

I am looking to day to see if I can follow where the FreeRTOS initial startup and follow-on task switching modify the (or at least switches between the) MSP and PSP register that manifest behind R13. That seems to be An area that is adding to my confusion and I suspect the source of my hard faulting… I expect I have something mis-configured.

6

Looks good. You’re using the right portable files.

Would be good to test by writing configASSERT(0) somewhere and verifying the expected results.

Yes SAU_CTRL defaults to zero, but no that doesn’t mean the processor is operating in secure mode. See here for the relevant ARM docs.

ST devices ship with TZ disabled completely. If you haven’t enabled TZ, then your device isn’t running secure. You can double check using STM32CubeProgrammer (not CubeIDE) to inspect the flash option bytes, which is where TZ is enabled/disabled. Is it possible your issues have nothing to do with TZ?

If you are using the CubeIDE debugger, the “Fault Analyzer” can be helpful. Debug, wait for the fault, then choose “Window → Show View → Fault Analyzer”.

7

It should not matter. If you are not using TrustZone features, you should be able to use NTZ port. The only thing that you need to ensure is that you define configRUN_FREERTOS_SECURE_ONLY to 1 in your FreeRTOSConfig.h if your processor is running secure.