cancel
Showing results for 
Search instead for 
Did you mean: 

STemwin hard fault if buffer in ext sram.

PBalo
Associate

Hello,

I have a project based on STM32F417ZET. I want to use the STemwin library (STemWin532_CM4_OS_GCC.a) provided by ST. I'm using FreeRTOS that's why the lib is the _OS_ version.

Two things attached to the uC via FSMC:

  • external SRAM
    • type: IS66WV51216EBLL-70TLI-TR
  • display controller
    • type: ILI9481

Everything is fine and works well if the buffer for the emwin is in internal RAM. If I move this buffer to the external RAM I get hard fault, more precisely unaligned access hard fault. I did some disassembly debugging the hard fault happens somewhere in __ALLOC function inside emwin.

#define GUI_BLOCKSIZE 0x80
#define GUI_NUMBYTES  (100UL*1024UL)
 
//This cause hardfault
static U32 extMem[GUI_NUMBYTES/4] __attribute__ ((section(".extram"))) = {0};
 
//This works fine
static U32 extMem[GUI_NUMBYTES/4]= {0};
 
void GUI_X_Config(void) 
{
   GUI_ALLOC_AssignMemory(extMem , GUI_NUMBYTES);
   GUI_ALLOC_SetAvBlockSize(GUI_BLOCKSIZE);
}

I tried 8/16/32 bit access to the sram, all test passed. The hard fault occurs only if I place the buffer in the external sram for emwin.

Does anyone experienced this kind of error? Any idea?

1 REPLY 1

>>I did some disassembly debugging the hard fault happens somewhere in __ALLOC function inside emwin.

That lacks specificity. It faults because it accessed memory that is not available. You need to look at the registers, and instruction that faults, and see what memory address it was touching. Figure where that is, and what the .MAP suggests it might be, and why/how the ALLOC function would be there based on the parameters you fed into it.

Is it attempting to call an error handler?

Is the CRC peripheral clock running?

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