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] [June 2016 Threads]
Hi:
when I set USEPREEMPTIONI to 1 and execute vTaskDelete(NULL), system halt.
when I set USBPREEMPTION to 0 and execute vTaskDelete(NULL), system is normal, but task is still alive.
I trace the vTaskDelete code, and find it will call YIELD task function ,
I use a software trap to do PendSV handler.. I know I should put the trap priority lower, but the cpu has no trap priority to configure... so, should I need disable it before issue the trap ?
Vincent
I found the problem is system halt yield task in ISR..it mean if yeild task in systick handler or other ISR. system will halt ..
anyone can give me a direction?
I think this is a port you are creating yourself, which means you need to have a deep understanding of how the architecture behaves when you execute the software trap. It might be that a software trap cannot be used in this circumstance, or if it can be used, that you need to ensure the trap entry and exit code performs any actions necessary to ensure the task restarts in exactly the same state (same register values, same stack, same stack pointer, same control register values, etc.). You could create a very simple system with just one task, then step through the asm code as it yields to itself (from an interrupt in your case I think) to see how registers are saved and then restored to see if you end up with an exact same system state after the task is restored.
Is the software trap held pending if you are in a critical section? If so, then it is probably ok, as the trap will execute when you leave the critical section and so execute normally. You can see examples of this in the Cortex-M ports. However, I expect that will not be the case, in which case you will need to save the critical section nesting count as part of the task context, and when restoring the task context use the value saved for the task to know whether to start the task again with interrupts enabled or disabled. You can use one of the many ARM7 demos for examples of how that is done.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.