I had a really annoying problem with FreeRTOS and my SAM7-256 board that I believe is a kernel bug. The issue I was having is that I needed system interrupts enabled before I was running the scheduler (to talk to various pieces of hardware), and I was occasionally getting bizarre register corruptions (value of 0xa5a5a5a5) after the first task was created. So about one out of every 10 times I turned on (or reset) the board, I’d get a data abort.
I traced the problem to vTaskIncrementTick and vTaskSwitchContext doing regular "processing" of tasks and switching out my existing pre-OS context while timer interrupts were enabled. vTaskSwitchContext checks for uxSchedulerSuspended, which by default is *FALSE*, causing it to (potentially) do a task swap outside of the OS running. Yikes!
My belief is that vTaskIncrementTick and vTaskSwitchContext should do absolutely nothing unless xSchedulerRunning is set to non pdFALSE. I added in:
if (pdFALSE == xSchedulerRunning)
in vTaskIncrementTick and vTaskSwithcContext, and my bizarre startup problems have gone away. Currently those procedures don’t look at the xSchedulerRunning boolean. My initial thought that this was something I should put in the port side of things, but upon further thinking about it, it looks to me as if having those procedures run on ANY platform when the OS is running is a bad idea.
Richard, care to weigh in on this one and perhaps fix?