Skip to main content
Visitor II
June 20, 2024
Question

Hard fault on Using FMC ram on stm32h753

  • June 20, 2024
  • 4 replies
  • 3601 views

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? 

 

    This topic has been closed for replies.

    4 replies

    Graduate II
    June 20, 2024

    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.

    sivaramAuthor
    Visitor II
    June 20, 2024

    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. 

    Technical Moderator
    June 20, 2024

    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

     

    sivaramAuthor
    Visitor II
    June 20, 2024

    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. 

    Technical Moderator
    June 20, 2024

    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 ..

    sivaramAuthor
    Visitor II
    June 20, 2024
    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.  
    Graduate II
    June 20, 2024

    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

    Visitor II
    June 21, 2024

    I'd suggest checking if the external RAM is properly initialized and if the memory regions are correctly configured in your linker script. Also, make sure the cache settings are appropriate for the external RAM. You might want to use the STM32's built-in debugging tools to step through and see where it fails.