FreeRTOS version: 202212.00
Port: NIOS for Intel/Altera
Running on Cyclone V
Port files copied from: Source/portable/GCC/NiosII
I inserted test code in my project’s main.c that simply writes 0x55 to external DDR and verifies the contents. My DDR starts at address 0x0000000000000000. My test fails because the first four bytes are being mysteriously written by something else.
When I remove the FreeRTOS files from the build, the memory corruption does not occur. So I started adding back the FreeRTOS files. It turns out that the memory corruption occurs when port_asm.S is included in the build. That file does require that pxCurrentTCB be defined, so I copied the tskTCB typedef, TCB_t typedef, and “TCB_t * volatile pxCurrentTCB = NULL;” into my main.c. No other FreeRTOS files are included in the compile and no FreeRTOS functions are called.
As I learned from another posting, port_asm.S inserts exception handling code ahead of the normal exception code and includes branches to bypass the normal exception code. Reference " FreeRTOS with Altera / Intel NIOS II, exception handling clash".
The issue I see is that pxCurrentTCB is set to NULL, which is the same as address 0x0000000000000000 (the same as the start of my external RAM). Therefore, if the exception code runs for whatever reason, the code in port_asm.S writes to my external RAM, causing the memory corruption.
It seems like the code in port_asm.S needs to have protection when pxCurrentTCB is NULL.
Perhaps the root question is, why is the code in port_asm executing in the first place since I am not calling any FreeRTOS functions.
What do you think is the best way to approach this? In my “real code” (rather than this test code) I will have various init and hardware test functions that happen before creating FreeRTOS tasks and get the scheduler going (at which time it would init pxCurrentTCB with something other than NULL). I don’t want my external RAM being corrupted during my RAM integrity check).