LPC MicrocontrollersのトピックRe: FreeRTOS bug in xQueueGenericSendFromISR ?

FreeRTOS bug in xQueueGenericSendFromISR ?

lpcware — Wed, 15 Jun 2016 20:24:49 GMT

Content originally posted in LPCWare by alramlechner on Fri Aug 07 07:03:51 MST 2015
Hi,

currently i am developing with the LPC1768 and the LPCOpen freertos_webserver project. i have extended the project with two things:

a) CAN ISR
b) an task (called CAN2LAN), that is working with an TCP connection

the scenario is very simple:
if the CAN2LAN task receives an TCP connections, it creates the queue.
the CAN ISR receives CAN Messages and puts them into a FreeRTOS queue (if the queue isn't null).

this is working fine. but doing some loadtests (here: sending 10 CAN messages per seconds via another CAN node), the system watchdog is resetting the processor in irregular intervals. so i changed the watchtdog to call ISR and not to reset de device. i had a look with the debugprobe and i see the following stack:

webserver_freertos.axf
Thread #1 <main> (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)
HardFault_Handler() at cr_startup_lpc175x_6x.c:324 0x1f4
<signal handler called>() at 0xfffffff1
uxListRemove() at list.c:202 0xc4bc
xTaskRemoveFromEventList() at tasks.c:1.985 0xd7d8
xQueueGenericSendFromISR() at queue.c:1.002 0xc9e4
CAN_IRQHandler() at can_task.c:269 0xe570
<signal handler called>() at 0xfffffff1
uxListRemove() at list.c:201 0xc4ba
xTaskIncrementTick() at tasks.c:1.646 0xd5d2
SysTick_Handler() at port.c:450 0xc660
<signal handler called>() at 0xfffffffd
prvPortStartFirstTask() at port.c:253 0xc55a
xPortStartScheduler() at port.c:330 0xc58a
0x0

after investigate some research, it seems clear, that this happens. but i don't know, what i did wrong.

the problem is the following (as far as i can see):
a) the CAN2LAN task is waiting (blocked)
b) the Systick_Handler gets called
c) the Systick_Handler decides, that the CAN2LAN task should be going into running state; so it removes the task from the waiting list (this happens here: uxListRemove() at list.c:201 0xc4ba)
c) in uxListRemove there is one line, that setting the container (=List?) of the item to null:
list.c:198

pxItemToRemove->pvContainer = NULL;

d) now there is a CAN ISR (received new message)
e) the qQueueGenericSendFromISR also tries to remove the CAN2LAN task from the waiting list and call's
f) uxListRemove() at list.c:202 0xc4bc
g) now the problem in uxListRemove(): this line
list.c:190

pxList = ( xList * ) pxItemToRemove->pvContainer;

returns null, because this item isn't (at this time) in any list.
that seems to force the HardFault_Handler getting called.

i thought, it should be safe, to call xQueueGenericSendFromISR() in the CAN ISR?
or: should the SysTick ISR running at higher priority, so that SysTick can interrupt CAN, but not in the other way?

can anyone give me a hint, what ist going wrong?

thanks!

Alram

Re: FreeRTOS bug in xQueueGenericSendFromISR ?

lpcware — Wed, 15 Jun 2016 20:24:49 GMT

Content originally posted in LPCWare by alramlechner on Fri Aug 07 13:28:29 MST 2015
just found it. IRQ priority, which uses FreeRTOS API, must have lower priority than SysTick ... (http://www.freertos.org/a00110.html#kernel_priority).

Re: FreeRTOS bug in xQueueGenericSendFromISR ?

lpcware — Wed, 15 Jun 2016 20:24:50 GMT

Content originally posted in LPCWare by Rob65 on Fri Sep 04 04:57:05 MST 2015
Thanks,

I had the exact same problem but it was not directly clear to me this had to do with interrupt priorities.
The system always gives the error in uxListRemove but not always with the stack frame you showed.

It got stuck every 20 minutes or so but after changing the interrupt priorities it has been running fine for hours :bigsmile:

Of course, I should have noticed the remarks in FreeRTOSConfig.h:

/* The lowest priority. */
#define configKERNEL_INTERRUPT_PRIORITY ( 31 << (8 - configPRIO_BITS) )
/* Priority 5, or 160 as only the top three bits are implemented. */
/* !!!! configMAX_SYSCALL_INTERRUPT_PRIORITY must not be set to zero !!!!
See http://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html. */
#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). */