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] [September 2009 Threads] Interrupts enabled during system initPosted by jdabbs003 on September 4, 2009 Hello. Our system boots, sets up the hardware, creates FreeRTOS tasks and queues, then starts the scheduler. The intent is that interrupts are disabled until the tasks start. However, FreeRTOS is enabling interrupts almost immediately because of the way critical sections work.
There are several ways to fix this. But, is there a "right" way?
RE: Interrupts enabled during system initPosted by Richard on September 4, 2009 See my answer to the last time you posted the exact same question.
Regards.
RE: Interrupts enabled during system initPosted by jdabbs003 on September 4, 2009 I have no idea how I managed to post this twice. This is a port, but I used the MSP430 as a starting point. The way that critical section works, it disables interrupts, then increments a counter when you enter it. When you leave it, it decrements the counter and re-enables interrupts when it gets to zero. The end result is that if you enter the critical section with interrupts disabled, you leave the critical section with interrupts enabled. During system boot, this is exactly what happens when I create the 1st message queue.
RE: Interrupts enabled during system initPosted by Richard on September 4, 2009 The critical nesting count in the official MSP430 ports is stored in a variable called usCriticalNesting which is initialised in port.c to 10. This means during initialisation critical sections will never see the nesting count reach zero, and once interrupts have been disabled they will remain disabled until the scheduler is started (at which point usCriticalNesting is set to 0).
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|