I’m working on a software application with FreeRTOS 10.2.1 + TCP + FAT + IO, for the Zynq Ultrascale+ RPU on an Ultrazed. I’m getting everything to start up succesfully through my main function, but halfway through one of my function calls I’m getting interrupted back to the beginning of “main()”, i.e it is being called again somehow. I’m using the exact same application code from a previous version of FreeRTOS, and did not have this behavior when I was running with FreeRTOS 9.0.1. I’m assuming it is something in my BSP source code or setting that is causing this behavior. Any leads/ideas would be appreciated at this point.
Hi Andrew,
Oops, that is a difficult question!
So when you change the kernel from 9.0.1 to 10.2.1, you get these spontaneous resets? main() is only called from the assembler start-up code, and when it is called for a second time, I assume that a CPU reset has taken place.
I think there is a reset function somewhere in the code. Would it be possible to find that function and put a breakpoint in it?
Thanks, that definitely gave me some stuff to look for, I’m definietely not calling a reset explicitly up to the point where my code returns to “main”. It seems to be resetting from inside the FF_RAMDiskInit function, but if I remove my function that does all of the initialization for the filesystem it ends up just doing the reset at another function. I get back to the beginning on “main()” and then I get:
HALT: Task $(k overflowed its stack.
Here are some of the FreeRTOS calls I make before the reset happens, could any of these be causing a reset somehow?
FreeRTOS_IPInit
xSemaphoreCreateMutex
FreeRTOS_IsNetworkUp
Xil_Out32(0xFF5E0000U + 0x00000220U, 0x0000007DU); // to clear reset reason after checking for why we reset last time
xTimerCreate
xTimerChangePeriod
xTimerReset
FF_CreateIOManger
FF_Mount
FF_FS_Add
None of these were causing a reset when ran with the older version of FreeRTOS, so I’m not sure why they would be now. I’ve been comparing configuration files and they all match between projects, so I’m pretty stuck at this point.
Thanks, that definitely gave me some stuff to look for, I’m definietely not calling a reset explicitly up to the point where my code returns to “main”. It seems to be resetting from inside the FF_RAMDiskInit function, but if I remove my function that does all of the initialization for the filesystem it ends up just doing the reset at another function. I get back to the beginning on “main()” and then I get:
HALT: Task $(k overflowed its stack.
Here are some of the FreeRTOS calls I make before the reset happens, could any of these be causing a reset somehow?
FreeRTOS_IPInit
xSemaphoreCreateMutex
FreeRTOS_IsNetworkUp
Xil_Out32(0xFF5E0000U + 0x00000220U, 0x0000007DU); // to clear reset reason after checking for why we reset last time
xTimerCreate
xTimerChangePeriod
xTimerReset
FF_CreateIOManger
FF_Mount
FF_FS_Add
None of these were causing a reset when ran with the older version of FreeRTOS, so I’m not sure why they would be now. I’ve been comparing configuration files and they all match between projects, so I’m pretty stuck at this point.
So I traced it down to always returning to the start of main and giving the me the “HALT: Task overflowed it’s stack” from within the FF_FlushCache function, which happens when I call FF_RAMDiskInit from within my application. I’ve tried it with the older version of the FAT stack I was using on my 9.0.1 kernel, and the newest version of the FAT stack that I downloaded and I end up with the same main reentry and stack overflow from within FF_FlushCache.