LPC2129 – FreeRTOS 6.1.1 – Tasks Colliding on Startup

LPC2129 – FreeRTOS 6.1.1 – Tasks Colliding on Startup Hi, A few years back I inherited from FreeRTOS code that I’ve been steadily adding features to. Recently, my tasks have stopped launching properly due to an apparent “collision” on startup. This is using GCC 4.7 and an ARM7 (LPC2129). I print to UART for debug, so that’s where I get most of my information. I create the tasks with:
if (!(TasksInitialized & TASKACCEL)) { if (TaskAccelInit() == 0) TasksInitialized |= TASKACCEL; } if (!(TasksInitialized & TASKGPS)) { if (TaskGPSInit() == 0) TasksInitialized |= TASKGPS; } if (!(TasksInitialized & TASKOBD2)) { if (TaskOBD2Init() == 0) TasksInitialized |= TASKOBD2; } if (!(TasksInitialized & TASKSD)) { if (TaskSDInit() == 0) TasksInitialized |= TASKSD; } if (!(TasksInitialized & TASKUPLOAD)) { if (TaskUploadInit() == 0) TasksInitialized |= TASKUPLOAD; }
and it seems that everything is initialized properly. Then, I allocate stack to the tasks.
xTaskCreate(vTaskAccel, (const signed char *)”Accel”, 46, NULL, tskIDLEPRIORITY+1, NULL); xTaskCreate(vTaskGPSParse, (const signed char *)”GPS Parse”, 50, NULL, tskIDLE_PRIORITY+1, &xTask_GPSHandle); xTaskCreate(vTask_OBD2, (const signed char *)”OBD2″, 100, NULL, tskIDLE_PRIORITY+2, &xTask_OBD2Handle); xTaskCreate(vTask_Record, (const signed char *)”Record”, 70, NULL, tskIDLE_PRIORITY+3, &xTask_RecordHandle); xTaskCreate(vTask_Upload, (const signed char *)”Upload”, 136, NULL, tskIDLE_PRIORITY+3, &xTask_UploadHandle);
When I start the scheduler with vTaskStartScheduler(), the first few tasks start, and I am able to print a message like “Task _____ started.” Once it gets to the last two tasks, it launches TaskUpload and TaskRecord concurrently (that is, TaskRecord interrupts TaskUpload – such that my print “* vTaskUpload Started” and “*vTaskRecordStarted” merge and form “* vTas* vTaskUploak_Recad() Sord() tartedStartn”). What might be happening here? Stack collision? Something else? I thought it could be due to sharing a common priority, but that code has been unchanged since 2011 and this is a new problem. On a related note, I’m attempting to upgrade to 7.5.2 and having trouble because something in the OS creates a .text section (6.1.1 did this when it defined ulCriticalNesting = 9999UL; and it stopped when I set it to undeclared and then define it in main.c). How might I find our which variable is causing this initialization so I can get a binary file > 1 GB? Thank you all!

LPC2129 – FreeRTOS 6.1.1 – Tasks Colliding on Startup

LPC2129 – FreeRTOS 6.1.1
That is very old!
if (!(TasksInitialized & TASKACCEL)) { if (TaskAccelInit() == 0) TasksInitialized |= TASKACCEL; }
What are these pieces of code doing? From your post it looks like you don’t actually create the tasks until after this sequence has executed, so maybe it is just initialising data that is going to be used by the tasks?
and it seems that everything is initialized properly. Then, I allocate stack to the tasks. xTaskCreate(vTaskAccel, (const signed char )”Accel”, 46, NULL, tskIDLEPRIORITY+1, NULL);
Calling vTaskCreate() is doing a lot more than allocating stacks to the tasks, it is actually creating the tasks. The stack is allocated to the task as part of the process of creating the task.
I am able to print a message like “Task _ started.”
A lot of support requests result from people trying to print from tasks. Are your print routines using mutual exclusion? Do you have enough stack in your tasks to handle a print function – which if you are using the GCC libraries will be massive. I can’t remember if V6.x.x had stack overflow detection, but if it did make sure it is turned on.
such that my print ” vTaskUpload Started” and “vTaskRecordStarted” merge and form ” vTas vTaskUploak_Recad() Sord() tartedStartn”).
…so you are not using mutual exclusion on your print function.
What might be happening here? Stack collision? Something else?
Don’t think so – it sounds like it is behaving as expected. Both the tasks you mention are running at the same priority, so there is no reason to suppose they will not interrupt each other. Processing time is shared between tasks of equal priority (time slicing). It is probably that your older applications ran in such a way you just didn’t notice it happening because each print message completed before the next started.
On a related note, I’m attempting to upgrade to 7.5.2 and having trouble because something >in the OS creates a .text section (6.1.1 did this when it defined ulCriticalNesting = >9999UL; and it stopped when I set it to undeclared and then define it in main.c). How >might I find our which variable is causing this initialization so I can get a binary file > 1 GB?
I’m not sure I follow this one, why do you need > 1GB binary image, and why would have a .text section prevent that. I would expect all the kernel code to be in the .text section, as that is the section that holds executable code. Normally the ulCriticalNesting variable will be the only one that is not initialised to 0, so it will appear in a data section other than .bss but not the .text section – although the value copied into the variable will appear in flash. If any others are then you should be able to see them from the .map file generated when you build your project (if your build is not generating a map file then you can request GCC creates one using the -Map=output.map linker option). Regards.

LPC2129 – FreeRTOS 6.1.1 – Tasks Colliding on Startup

Thank you! Yes, it is very old (and it does have stack overflow detection that seems to work intermittently). That’s why I’d like to update to 7.5.2. I also flipped my < and < signs, the problem with 6.1.1 was that when ulCriticalNesting was defined it created two sections aligned 1GB apart. By initializing it at runtime instead, the section was not created and the filesize was reduced to ~65kb. In 7.5.2, there’s something else creating a new section causing the massive filesize again, but I don’t immediately see what. I’ll check the .map again. Those bits of code (TaskAccelInit), etc. populate the startup variables prior to creating the task. There’s no mutual exclusion on the print (obviously), but haven’t had a problem until recently. The weird thing about the task collision is that, as I understand it, it should be running as a “round robin” – but after the collision, all tasks stop. It remains apparently frozen until the watchdog kicks in and the whole thing resets. My shot in the dark (I’m a mechanical engineer, so please forgive my naivety here) is that, perhaps my tasks have now increased their processing requirements to the point a round-robin scheme simply will not hand off control (one task demands 100%, e.g.). Perhaps paring things back a bit will help for the time being. We don’t have JTAG support on these boards and use a plaintext editor for code, so I’ll have to see about getting a simulator set up or figuring out some other method of debug. Thanks again – I really appreciate the help. Hoping that an upgrade to 7.5.2 will help things as well.

LPC2129 – FreeRTOS 6.1.1 – Tasks Colliding on Startup

created two sections aligned 1GB apart
Sounds like your linker script is wrong.
point a round-robin scheme simply will not hand off control
If you have configUSE_PREEMPTION set to 1 in FreeRTOSConfig.h then the tasks will time slice automatically. A context switch will occur between two tasks of equal priority on the tick interrupt. One task does not need to hand off to the other. It is possible for lower priority tasks to get starved of processing time if higher priority tasks are using all the available time though. Regards.

LPC2129 – FreeRTOS 6.1.1 – Tasks Colliding on Startup

Well, some interesting debug results. FreeRTOS 7.5.2 is up and running (solved the linker problem so it fits in code space) but the update didn’t solve my problem on a piece of new hardware. I tested the same code on an old board and it ran as expected. The new board, using the same processor, starts a task/set of tasks of the same priority (highest to lowest), loops once, and hangs. It doesn’t matter what priority level, if it’s one or two tasks, or which task is being run – it’s the same behavior for each. Start, loop, no more processing. I suspect the problem may be hardware and this could be the wrong forum, but I’m at a loss. Given the new hardware is identical to the old hardware save for the power supplies, I’m wondering if anyone has seen this before and has suggestions to debug? If it was the crystal, I suspect I wouldn’t get a proper UART print out of it. My theory is I might be browning-out (unable to deliver power required), but it seems unlikely that simply launching a task would cause such a power surge — given that all the peripherals are initialized before the tasks start, anyway. Even tips on how I might see the last operation prior to freezing would be appreciated. The supplies are rated to 500mA and the solder joints are good, so I’m at a loss here.