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] [March 2016 Threads] FreeRTOS v7.5.3 IAR EWARM 7.40.1.8472 with LPC4350Posted by gregd29 on March 15, 2016 I have an application that I have been using FreeRTOS v7.5.3 with IAR EWARM 7.4.1.8472 on an LPC4350 for the past few years. I am using the IAR Cortex-M4F port. I recently had a board lockup where I determined that the code was stuck in the Idle task with the BASEPRI register set to 0x20. This was keeping the SysTick interupt from triggering and thus keeping all the other tasks from ever running. As far as I can tell, you should never have a non zero value in the BASEPRI register when an actual task's code is running unless the task has called portDISABLEINTERRUPTS() or taskENTERCRITICAL(). The Idle task doesn't seem to be calling these functions at least in the three or four spots it is looping around. Has anyone ever seen this before? Do any of the newer versions have improvements to avoid this in the Cortex-M4F port?
At this point I have not ruled out some type of hardware failure - data or code access failures. I was just wondering if this has been seen before and if any possible causes may be known.
Thanks,
Greg Dunn
FreeRTOS v7.5.3 IAR EWARM 7.40.1.8472 with LPC4350Posted by rtel on March 16, 2016 Have you read through the My Application Does Not Run, What Could Be Wrong page of the FAQ?
I'm not aware of anything in any version of FreeRTOS that could cause such an issue. The most common cause of problems is incorrect interrupt priority assignment, although this would not be a typical symptom. Later versions of FreeRTOS have many more configASSERT() points that could help catch such issues though.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|