Low priority tasks stop getting scheduled despite idle activity on LPC1517 (Cortex M3)

jdupre wrote on Thursday, March 24, 2016:

System is NXP LPC1517 running FreeRTOS V8.0.1. I got the base code from the LPCOpen library. Using LPCXpresso IDE (GCC). Chip running at 72MHz, FreeRTOS tick is 1ms interval.

I have 3 tasks:

TaskSystem: priority 0
This is the first task to run. It loads user settings from eeprom, then creates the additional tasks. vTaskDelay() pauses it for 10 seconds then checks for for changes to the user settings and saves if necessary.

TaskSerial: priority 1
Serial ISR gives semaphore via xSemaphoreGiveFromISR() to task when data frame is recieved. The task then updates an LED display if data has changed, and calculates a value to set a match point for a timer. This happens about 40 times per second when active. When inactive, xSemaphoreTake() times out after 1250ms to signal inactivity by changing the display.

TaskUI: Priority 2
ISR is triggered when any 1 of 3 buttons is pressed or released. The ISR detects which button(s) were pressed or released, does some debouncing, uses xTaskGetTickCountFromISR() to measure how long button was held down, and then xSemaphoreGiveFromISR() signals task to process the button activity. When there is no button activity, xSemaphoreTake() times out after 5 seconds and prints out high water marks for each task. (Except the idle task-- not sure how to do that.)

Independent of the OS is a counter-timer peripheral ISR that is set at the highest IRQ priority. It is triggered at 60Hz.

Under “normal” operation everything appears to operate as expected. However, when I do a “monkey test” (randomly pressing the buttons rapidly), the lower priority tasks stop running. Even after the buttons are no longer pressed, and the TaskUI’s xSemaphoreTake() times out, the other tasks do not get scheduled. There may well be logical errors in how my ISR handles the button presses, but that shouldn’t affect other tasks should it?

I have verified that the IRQ for TaskSerial is still getting called, but giving the semaphore to the task does nothing.

I moved the high water mark test to the UI Task, and no task reports less than 17.

I have watermarked all 12K of RAM at startup, and it appears there is still at least 7K of untouched RAM after the low priority tasks stop running.

Any ideas why this is happening? What else can I test for?


  • Joe

richard_damon wrote on Friday, March 25, 2016:

Have you defined configASSERT()? You say that you have an ISR at the ‘highest’ priority. I don’t know about the LPC port, but many ports define a max priority that a interrupt may have and still be able to call FreeRTOS API functions, and having an interrupt higher than that can cause the sort of thing you describe (the too high priority ISR bypasses critical sections and corrupts some of FreeRTOS’s internal state)