The thing that I am trying to do is reload the R5 core with my application that uses FreeRTOS as the OS. I have around 6 user tasks. The very first load, everything works fine but the second time, when I am loading the ELF on to the R5 cores, I see that only the idle task is running but none of the other tasks are running, although all 6 tasks are created successfully. Please note that, I am trying a reload of the R5 core without a board reboot.
Is there anything more that I need to take care with respect to the RTOS? I have some suspicion that the RTOS ticks are not getting generated or the R5 core is not getting interrupts. Is there any way to confirm this?
I am using the remoteProc to load the R5 cores from Linux.
Is there anything more that I need to take care with respect to the
RTOS?
Not in the RTOS, but yes in the hardware. It would be advised to
disable interrupts until the RTOS starts again (at which point they will
become automatically enabled again), and to completely re-initialise the
clock used to generate ticks (including ensuring there are no interrupts
already pending).
Also, when you load the elf file, does it run through the C start up
routes again to re-initialise the interrupt controller/vectors, clear
the bss section, initialise the data section, etc. ? I’m not sure of
your architecture, but suspect it is dual core (at least), in which case
it is possible that that initialisation was done elsewhere the first
time you load the image and you need to do it again manually the second
time. If you place a break point at the start of main() and inspect
variables that should be initialised to a non-zero value and then have
changed from their initial value during the first run, do they have
their expected initial value again?
I have some suspicion that the RTOS ticks are not getting
generated or the R5 core is not getting interrupts. Is there any way to
confirm this?
The simplest way is to put a break point in xTaskIncrementTick() inside
FreeRTOS/source/tasks.c. Additionally, let it run for a while then
inspect the value of xTickCount in the same file - it should be
incrementing at whatever the tick frequency is.
Hey Richard, thank you for your respose.
Regarding the architecture, you are correct, I am running two R cores in split mode on the Zync Ultrascale SoC.
In fact I did confirm that, the OS ticks are not getting generated. I do not see the xTickCount incrementing the second time I load the ELF. So I will have to check why this is happening.
Not sure if the interrupt itself is not happening or the ISR vector table has gone haywire.