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] [August 2012 Threads] Exiting the Kernel Posted by wade dawson on August 3, 2012 Hi. I have an arm cortex m3 (lpc1758) freeRTOS application that is a bootloader, It lives in low memory, runs on a FreeRTOS task , gets pristine hw out of reset then either programs some other memory in the system from a USB flash drive and drives a nifty LCD display OR executes a completely separate image with its own kernel and views on how things should be done. This OTHER body of code attempts to kill-off FreeRTOS's ISRs (PendSV, Systick, SVCALL), then installs it's own set of handlers by moving the vector table, etc. This has been working until recently. Now I'm getting an InvPC Usage fault from the Cortex M3 when the other kernel tries to its context switching magic. If I trace the UsageFault via the stack frame, it points to FreeRTOS's vPortYieldFromISR. Even though the OTHER body of code attempts to clear the pendsv and svcall pending bits the NVIC. My question is:
How can I ensure that FreeRTOS is indeed done and will not have stacked exceptions to return to / from or any other other pending exceptions before I yank the exception vector table out from under it?
Any help would be greatly appreciated as this is a difficult issue (for me) to debug!!
-Wade
RE: Exiting the Kernel Posted by Dave on August 3, 2012 If you have actually moved the interrupt vector table, then the only way a FreeRTOS interrupt handler could execute after would be if you had copied the FreeRTOS handlers into your new vector table, or you moved the vector table from an interrupt that had nested with an already existing FreeRTOS handler.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|