FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [July 2011 Threads] SIGSTOP from IDLE task (LPC11C14, CodeRed)Posted by Dave Nadler on July 11, 2011 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
RE: SIGSTOP from IDLE task (LPC11C14, CodeRed)Posted by Richard on July 11, 2011 “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.
RE: SIGSTOP from IDLE task (LPC11C14, CodeRed)Posted by Dave Nadler on July 11, 2011 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
RE: SIGSTOP from IDLE task (LPC11C14, CodeRed)Posted by Dave Nadler on July 11, 2011 Hi Richard - A bit more info, FYI, note mods to FreeRTOS... http://knowledgebase.nxp.com/showthread.php?p=10075#post10075Any ideas would be appreciated; I'll keep digging... Thanks, Best Regards, Dave
RE: SIGSTOP from IDLE task (LPC11C14, CodeRed)Posted by Richard on July 12, 2011 “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.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|