cancel
Showing results for 
Search instead for 
Did you mean: 

Hard fault on Using FMC ram on stm32h753

sivaram
Associate III

I'm using a STM32H753 with external RAM. We were using it for LCD framebuffer. Now we are trying to migrate the stack and heap to the external RAM, when we run the code, getting hardfault on lines where std::array is declared. Any idea on how to debug further? 

 

11 REPLIES 11

Don't put the stack in external RAM, it will make everything slower.

If you get a Hard Fault it's because you're using memory before the peripheral and interface is up and running.

For the compiler run time to initialize you want.to be initializing external memories early, in SystemInit() along with your clocks.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
SofLit
ST Employee

Hello,

As @Tesla DeLorean the memory interface (FMC) is not prepared/initialized before the main() so you need to initialize it in SystemInit(). See also this thread.

Meanwhile, what is the reason to move the Stack and heap to the external memory? is there a size lack of the internal one?

I agree with @Tesla DeLorean the execution will be slower but the cache could compensate that at a certain level. The best location to locate the stack/heap is the DTCM for execution determinism. You can refer to the AN4891 "STM32H72x, STM32H73x, and single-core STM32H74x/75x system architecture and performance" / Section 5.1 Software memory partitioning :

SofLit_0-1718876770820.png

 

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.

That already taken care of, we followed the example given in the cubemx, initialized the FMC in the systeminit. We are using freertos all the tasks are up, what is strange is the hardfault occurs on the std:array declaration line in one of the task. 

Initially we were using Internal RAM only for the stack and heap, but features kept on added and we ran out of internal memory, hence we are trying to move to external ram. 

SofLit
ST Employee

We were using it for LCD framebuffer. Now we are trying to migrate the stack and heap to the external RAM, when we run the code, getting hardfault on lines where std::array is declared. 

It could be your stack is overwritten / or overlapped with your frame buffer. Not easy to tell you why the HF happens .. Need to debug that ..

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
This is our memory map, the frame buffer sits in SDRAM and the bss, stack, heap sits in SDRAMEX
MEMORY
{
  DTCMRAM    (rwx)    : ORIGIN = 0x20000000,   LENGTH = 128K
    ITCMRAM    (rwx)    : ORIGIN = 0x00000000,   LENGTH = 64K
    RAM_D1    (rwx)    : ORIGIN = 0x24000000,   LENGTH = 512K
    RAM_D2    (rwx)    : ORIGIN = 0x30000000,   LENGTH = 256K
    RAM_D3    (rwx)    : ORIGIN = 0x38000000,   LENGTH = 64K
    FLASH (rx)  : ORIGIN = 0x8080000, LENGTH = 1536K
    QSPI (xr)  : ORIGIN = 0x90000000,  LENGTH = 8M
    DMA    (rwx)    : ORIGIN = 0x30040000,   LENGTH = 32K
    SDRAM (rw) : ORIGIN = 0xC0028000, LENGTH = 2M
    SDRAMEX(rw): ORIGIN = 0xC0500000, LENGTH = 3M
}
 
we are wondering how to debug further, the current behaviour is program enters main, all tasks are created and starts running, hardfaults on std::array declaration statement, we verified that task stack is not overflown, the same code when mapped to internal ram, works without any issues.  

So C++, does it fault whilst initializing the constructors?

/* Call static constructors */
bl __libc_init_array

What's the fault reporting, exactly?

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

bl __libc_init_array executes without any issues and enters main() too.  

if we have the following code, 

std::array<uint8_t, 12> Buff{};
std::pmr::monotonic_buffer_resource resource(
      Buff.data(), Buff.size(), std::pmr::null_memory_resource());
The Program counter on hardfault was pointing at 
"_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcENSt3pmr21polymorphic_allocatorIcEEE7reserveEj"
We verified that the same code executes without any issues when the stack and heap was configured in internal RAM. 

Ok, but what address is the allocator furnishing here?

Can you instrument __sbrk ? Or whatever is serving up space?

Sounds like something is walking into the end-of-memory. The FMC setting will scope the address decode space of the SDRAM

What are the instructions/registers for the MCU at the point of failure?

How large is the SDRAM? Show initialization code for it

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..