LPC178x Systick and interrupts

frankandersen wrote on Thursday, March 01, 2012:

I am trying to find out why my project ends up in vListInsert:

/* *** NOTE ***********************************************************
If you find your application is crashing here then likely causes are:
1) Stack overflow -
   see http://www.freertos.org/Stacks-and-stack-overflow-checking.html
2) Incorrect interrupt priority assignment, especially on Cortex M3
   parts where numerically high priority values denote low actual
   interrupt priories, which can seem counter intuitive.  See
   configMAX_SYSCALL_INTERRUPT_PRIORITY on http://www.freertos.org/a00110.html
3) Calling an API function from within a critical section or when
   the scheduler is suspended.
4) Using a queue or semaphore before it has been initialised or
   before the scheduler has been started (are interrupts firing
   before vTaskStartScheduler() has been called?).
See http://www.freertos.org/FAQHelp.html for more tips.

for( pxIterator = ( xListItem * ) &( pxList->xListEnd ); pxIterator->pxNext->xItemValue <= xValueOfInsertion; pxIterator = pxIterator->pxNext )
/* There is nothing to do here, we are just iterating to the
wanted insertion position. */

To me it looks like the Systick interrupts preempts the USB interrupt:

In FreeRTOSConfig I have:

/* Use the system definition, if there is one */
#define configPRIO_BITS       __NVIC_PRIO_BITS
#define configPRIO_BITS       5        /* 32 priority levels */

/* The lowest priority. */
#define configKERNEL_INTERRUPT_PRIORITY ( 31 << (8 - configPRIO_BITS) )
/* Priority 5, or 160 as only the top three bits are implemented. */
#define configMAX_SYSCALL_INTERRUPT_PRIORITY ( 5 << (8 - configPRIO_BITS) )

/* Priorities passed to NVIC_SetPriority() do not require shifting as the
function does the shifting itself.  Note these priorities need to be equal to
or lower than configMAX_SYSCALL_INTERRUPT_PRIORITY - therefore the numeric
value needs to be equal to or greater than 5 (on the Cortex M3 the lower the
numeric value the higher the interrupt priority). */


And in SHPR2 the value is 0xF8F80000, which I belive is the lowest priority?

How is priority between the peripherals interrupts and system interrupts?

I have a pin toggling in the TICK_HOOK and a pin in the USB it handler, when the system crashes the USB interrupt is Active and then the TICK_HOOK is called.

Any Ideas?

Best regards,

Frank Andersen

rtel wrote on Thursday, March 01, 2012:

Interrupt priorities look ok *provided* the LCD interrupt does not call any FreeRTOS  API functions.  Only interrupts at priority 5…31 can do that with the settings you have.

What else is you USB ISR doing?  Is it only calling API functions that end in “FromISR”?  Do you have stack checking on?


frankandersen wrote on Friday, March 02, 2012:

Well, how come that the solution alwys shows up when you ask a question.

It turned out that the USB call to xQueueSendFromISR, not always was within the interrupt, the call is used from a callback function so it was not that obvious.

Best regards,
Frank Andersen