Debug Hard Fault triggered when ETH is active with TrustZone enabled

[minchingho_span]

Hi,

    I'm working on root cause a Hard Fault issue on STM32H563. The application is a regular ping and response. The system has TrustZone enabled. When the hard fault happens, according to pushed stack info from psp_ns, the call happens inside a memchr function with some invalid char string address called from print function. I tried to step through the print function and hard fault always happened before I really get close to where the problem was reported. If I inspect the psp_ns info when hard fault happens during stepping through the code, it still shows exactly the same info ( issue in memchr with the same invalid pointer). This got me think the hard fault actually happened on the secure region. I also notice there is a value in psp_s, which shows 0x30007F88. I don't know how to view the stack info. I am also not sure if there is some memory conflict happened in this area since ETH DMA uses SRAM3 to process the data. Any suggestion how I can check what happened on the secured side? 

Thank you,

Min-Ching Ho

[STea]

Hello @minchingho_span ,

I think your issue is most probably related to you configuration of the Ethernet in conjunction with Trustzone and memory aliasing issues I recommend you take a look at the tow following articles which can help you greatly in this matter:

- How to debug a HardFault on an Arm Cortex®-M STM32 - STMicroelectronics Community

-How to create a IPv4 NetXDuo Ethernet UDP applicat... - STMicroelectronics Community
Regards

[minchingho_span]

@STea 

    Thank you for the info. I tried to follow the post for ETH configuration. I am confused by the linker script provided in the post. The ETH is set to non-secure region, according to your post. But, the linker file are added Rx/Tx descriptor to secure region. Why is that? I tried the configuration regardless my question above. I still hit hard fault. Any other suggestions for debugging this issue?

Best,

Min-Ching Ho

[STea]

Hello @minchingho_span ,

the Descriptors are placed in SRAM3 region and given access by the non-secure region they are not placed in a secure area, but this is done because all memory attributes are set to secure by default.

to help you debug the Hardault and know if this related to security attributes you need to recover the call stack or use some debug tools in your IDE such as fault analyzer to help you know the origin of your issue.
unfortunately, I can't help you further unless i get your project and try to debug it on my own. 
Regards

[minchingho_span · Accepted solution]

We have found a solution. It seems the problem is not really related to secure zone. It seems purely a vsprint implementation issue. We have fixed this problem by use different format to print the message.