I have a problem running an application that utilizes 10 timers and a single scheduled task on the TI Hercules RM48L852 processor. Specifically, running on the PGE package of this processor, not the ZWT one that ships on their Hercules HDKs.
I created my application by generating a PGE set of drivers using the TI Halcogen Tool.
I pulled over FreeRTOS OS files from the similar ZWT project I was using before our PGE production hardware was available. This incl. copying the demo projects from TI memory maps which are identical between ZWT and PGE variants of the processor.
Everything compiles and builds. However, once I start my timers on the PGE chip I get crashes.
I believe I have plenty stack for the application and the timers. One reason being that I have ran this successfully for a long time on the ZWT package.
The debugging of he call to xTimerStart that leads to the crash is as follows
call MPU_xTaskGetTickCount() : Successful
call xTimerGenericCommand()
call xQueuGeneric Send()
step to os_queue.c line 613 xTaskRemoveFromEventList()
step to os_list.c in vListRemove line (pxlist->uxNuimberOfItems) –
Processor hangs
pause debugger and you are in dabort with no RAM of Flash errors
step through to custom_dabort
then in the loop of being returned to instructions in os_list.c and then back to dabort
Note: I successfully create the timers.
I’m now in need of some assistance in tracing the reason why things fall apart after calling xQueueGenericSend(), is it the case that there is not enough stack?
So the exact same code works without a problem on the ZWT, but crashes on the PGE. What is the difference between the two. You said the memory map was the same, so there must be something else different.
MPU_xTaskGetTickCount()
That looks like a Cortex-M3 MPU port function, not a Cortex-R4 function. Where did you get the code from? Which version of FreeRTOS is it?
So is the demo you reference using the MPU? The function name looks like it is. I have not seen FreeRTOS running on an R4 with the MPU, thinking only the M3 MPU was supported.
Also have a look at the errata for the two chip versions. Maybe the newer chip behaves differently making it necessary to change the port code?
With stack overflow checking enabled the result is the same. So I think that verifies my stack allocation is OK.
I think you might be right on the MPU settings but TI did not pick up on this as being an issue. As long as you use the latest FreeRTOS projects in version 3.0.6 of HALcogen the MPU support is added. Requires you start the tasks in privileged mode.
Actually, I’m not sure that the timers will make a difference because all communication with the timers task is through a queue, I would have to check.
However, in the mean time I have got information from TI that the two parts you are using should be identical as far as FreeRTOS is concerned - only the packaging is different. Are the Halcogen files you are using in the two projects the same? What else is different in the projects?
No. Or to be more specific, I do not have a problem creating the timers only when I try to start them. At this point they get put in the queue which it would seem is where the problem arises.
I ran a small test a week ago where I had a single task that would create and launch up to 5 timers. On trying to start the 3rd timer the system would exhibit the fault.
The problem is definately something to do with timers, I just don’t know enough about this area to nail it down as the processor is sent to no-mans land.
Are the Halcogen files you are using in the two projects the same?
The HALcogen filesets (non os_) are not identical. I generate a 950PGE set for the RM48952PGE processor we are using. As I understand it the only difference between 950PGE and 952PGE is the max clock speed. Otherwise they should be compatible.