Hi - I'm using FreeRTOS 7.0 on LPC11C14, using CodeRed toolchain.
The application works great - until it crashes.
This happens after processing typically 50 - 200 CAN messages.
I'm getting a SIGSTOP, apparently in the IDLE task.
The application receives CAN messages in the background.
CAN ISR posts a msgobj# (one byte) entry into a 5-deep queue.
A task blocks on the queue, dequeues the msgobj#,
retrieves and processes the message, then blocks.
Debugging the hardfault in CodeRed is not working,
so I've added a few volatile flags to see what is active:
- the CAN ISR is not active
- the foreground CAN task is not active
Task pane in CodeRed says IDLE task is active.

I tried increasing the stack size without any effect.

Any ideas what to try, or how to debug this ?
Thanks in advance for any help !!!
Best Regards, Dave

“Hi - I'm using FreeRTOS 7.0 on LPC11C14, using CodeRed toolchain.”

That is not an official port (yet) so the assistance I can give is very limited.

“The application works great - until it crashes.”

Stack sizes is one of the obvious ones, but it looks like you have tried that. You could turn the stack checking on, or try and determine the stack high water marks for more certainty (there was another thread today on this forum about that).

I'm not sure how the interrupts work in the port you are using - but if it is anything like the CM3/4 ports, then the most common cause of error is an interrupt service routine having an incorrect priority. If you port has a configMAX_SYSCALL_INTERRUPT_PRIORITY or a configKERNEL_INTERRUPT_PRIORITY definition then take a look at point three here: http://www.freertos.org/FAQHelp.html

Regards.

Don't they all ;o) Of course, some work great longer than others.

All tasks show plenty of available stack space,
including the IDLE task (thanks again for helping
with that). A few more bits of information:

config\FreeRTOSConfig.h: #define configMAX_SYSCALL_INTERRUPT_PRIORITY0 /* 0 is highest "normal" M0 priority */
config\FreeRTOSConfig.h: #define configKERNEL_INTERRUPT_PRIORITY0 /* [dependent of processor] */
The systick builtin interrupt has a higher priority, but everything else is by definition lower priority (numerically 0 or greater).

no use of non-API functions in ISR; ISR only uses:
portBASE_TYPE taskUnblocked; // we hope that this will unblock CAN rx task...
xQueueSendToBackFromISR(CANrxQueue, &msg_obj_num, &taskUnblocked);
if(taskUnblocked==pdTRUE) {
// tell FreeRTOS to switch context to the CAN rx task, which is not automatic...
vPortYieldFromISR(); // because portSWITCH_CONTEXT(); is not implemented in this port...
}

Any other ideas ?
Thanks again,
Best Regards, Dave

Hi Richard - A bit more info, FYI, note mods to FreeRTOS...
http://knowledgebase.nxp.com/showthread.php?p=10075#post10075
Any ideas would be appreciated; I'll keep digging...
Thanks,
Best Regards, Dave

“Hi Richard - A bit more info, FYI, note mods to FreeRTOS...
http://knowledgebase.nxp.com/showthread.php?p=10075#post10075”

Like I say, its not a port I have written so can't comment on its implementation - but I will write one soon (ish) so thanks for the link.

Regards.