FreeRTOS 6.1.1 - vTaskDelayUntil FAILS, only on certain hardware (ARM7/LPC2129)

jsiegel2 wrote on Friday, October 04, 2013:

I’m troubleshooting an error with FreeRTOS 6.1.1 where my code never passes vTaskDelayUntil on a newly-constructed circuit board. The MCU and connected devices are identical to older boards, which work with the same code. The only changes are in the power supply and I don’t see errata that would indicate a change in hardware after a certain date. It’s possible that there is an assembly error - but if it were a crystal, I wouldn’t be able to get UART data.

What might make vTaskDelayUntil(&xLastWakeTime, Task_Period) fail? How can I best troubleshoot? If I comment out this line, the code runs properly except the lack of delay. If I leave the line in, the code never moves on.

Thank you.

edwards3 wrote on Friday, October 04, 2013:

Is the tick interrupt firing? If not time would stand still and the delay would never expire.

jsiegel2 wrote on Friday, October 04, 2013:

Why would the tick interrupt fire on one board but not the other while using the same processor? I was thinking along these lines but can’t explain it, unless the address changed… which should be in the errata.

rtel wrote on Friday, October 04, 2013:

Very strange.

By default, the LPC2129 port generates the tick interrupt from a peripheral timer. I would have thought it extremely unlikely that would move in the memory map between chip revisions.

Are you using the exact same software build, and the exact same compiler version?

Do you have debug access to the chip once it is on your hardware?


jsiegel2 wrote on Saturday, October 05, 2013:

The port I am using generates the tick interrupt using the default T0. The software tested on each is from an identical binary and installed from an identical SD-card bootloader, so no differences there. A second board from the new batch demonstrates the same hangup.

Unfortunately, I do not have debug access on these boards as they were designed as “production ready” (if anything ever is), so I’ve got limited peripheral output. For now, I’ll put a request in to NXP as I’m doubting this is a problem with the RTOS. Thank you for your help, and I still welcome any suggestions.

jsiegel2 wrote on Monday, October 07, 2013:

No reply from NXP yet, though I have managed to track down the offending code – it makes it to portYIELD_WITHIN_API(); from a number of different paths and then hangs indefinitely. Still works fine on the old board.

I’m not familiar enough with the ARM7 architecture to pursue much further, though I will do what I can and post the solution if I stumble into one.