Hello, I am using FreeRTOS v8.2.1 with an STM32F429. I have several tasks that run in parallel and all runs fine if I have the heap (I am using heap4.c) in the internal RAM. If I move the heap to the external SDRAM then I have sometimes (random times) hardfault coming (due to usage fault INVPC). The external SDRAM is working as I do several tests at startup (address bus, data bus…), and I did extensive tests on the hardware (several hours). Also I can use external SDRAM to store large arrays and I never had a problem with it. The problem happens only when using the external RAM as heap for FreeRTOS. My problem is very similar to https://sourceforge.net/p/freertos/discussion/382005/thread/b35f0426/ I tried to play a little with the RAM timings, but it does not seem to help. I did check where it hangs, and it is always during a POP instruction, per example: POP {r4-r8, pc} I used the method described under: http://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html also if I check the lr address it is always the same and points to the end of function vPortExitCritical just after portENABLE_INTERRUPTS. I have several interrupts enabled (all of it are below configLIBRARYMAXSYSCALLINTERRUPTPRIORITY and by below I mean bigger numbers so that they are disabled by FreeRTOS when needed). I did also realized that if I disable one of my interrupts (I have a EXTI that comes 4000 times per second) then the system seems not to crash anymore. In this interrupt I don’t use any FreeRTOS functions, I simply clear the flag and launch a DMA data transfer. At the beginning I was thinking it was a stack corruption, bit I did checks on the stacks of the tasks, and all tasks have more than enough stack. Any hints to try to find the possible cause are welcome. Thanks in advance, Ricardo

Apologies for the delay in replying – I only just saw your post! This is a curious one. I would guess the issue was relating to having the stacks in external RAM, although I’m not sure why that would be a problem. Is the RAM 32-bits wide and fast? Is there any cache inside the RAM? The reason for asking about the cache is that on other larger systems that have data caches in the processor itself there can be certain hoops that need to be jumped through in order to get the cache and a DMA to play nicely together – and you mentioned DMA. The pop instruction is loading the program counter, so the fault may be an invalid address going into the program counter. I’m just looking through the errata sheet: Is your RAM using the FMC (Flexible Memory Controller)? If so could it possibly be related to this errata (note it only relates to revision ‘A’ chips) – From DM00068628.pdf: 2.9.4 Corruption of data read from the FMC Description When the FMC is used as stack, heap or variable data, an interrupt occurring during a CPU read access to the FMC may results in read data corruption or hard fault exception. This problem does not occur when read accesses are performed by another master or when FMC accesses are done when the interrupts are disabled. Workaround Two workarounds can be applied: • Do not use the FMC as stack or heap, and make sure CPU read accesses to the FMC are performed while interrupts are disabled • Use only DMAs to perform read accesses to the FMC. This limitation is present only in revision “A” devices. It is fixed in revision “Y”, “1” and “3”. Regards.

Hi, Thanks for you reply. So about the RAM, I use the same as on the 32F429IDISCOVERY board from ST. It is a IS42S16400J-7 It is a 16 bit bus, I have a HCLK at 167.936 MHz, and use a prescaler of 2 for the RAM, so the clock is at half of it. I don’t think there is any cache on the RAM itself, I have checked the datasheet and nothing about it. Also about the DMA, I actually use the DMA from an SPI peripheral directly to the internal RAM no to the external RAM. External RAM I don’t use with DMA (at least not yet). I use the FMC, but I have a revision 1 device, so that the errata issue should not be present. Until I find I fix I will revert back the stack to the internal RAM. Many thanks for your help and support, Best regards,