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 2015 Threads] Timers period are affected after allocate memory [LPC1759]Posted by ricardo_crudo on August 6, 2015 Hi.
I'm running FreeRTOS 7.4.2 over LPC1759. The problem was isolated creating a code to blink leds using timer0 and timer1. In this case I'm allocating memory before create any task or call vTaskStartSchedule. I holds the execution putting a while(1) just before the memory allocation and the leds blink as expected, but if while(1) goes just after the memory allocation line, leds blinking period are affected. The period becomes quite bigger than before. Going into the freeRTOS code I found out this starts to happen afer call xTaskResumeAll function in pvPortMalloc.
I'm using a older FreeRTOS version because this code come from an already existing project. It used to work with 1788.
Any thought is appreciated.
Timers period are affected after allocate memory [LPC1759]Posted by rtel on August 6, 2015 I'm a little confused by your post, but think you have the following scenario:
- The scheduler has not been started yet.
- You are using two hardware timers to blink LEDs, one LED per timer.
- After a call to pvPortMalloc() the rate at which the LEDs are blinking changes.
Is that correct?
Are your timers using interrupts? If so, then interrupts are deliberately left masked (up to configMAXSYSCALLINTERRUPT_PRIORITY) once you start using the FreeRTOS API. That is done to prevent any interrupts attempting to use the scheduler before the scheduler has been started.
Regards.
Timers period are affected after allocate memory [LPC1759]Posted by ricardo_crudo on August 7, 2015
Is that correct?
yes, that's correct.
Are your timers using interrupts?
Are your timers using interrupts? If so, then interrupts are deliberately left masked (up to configMAXSYSCALLINTERRUPT_PRIORITY) once you start using the FreeRTOS API. That is done to prevent any interrupts attempting to use the scheduler before the scheduler has been started.
Yes, they're using interrupts. This mean I can't allocate memory before start the scheduler?
Thanks.
Timers period are affected after allocate memory [LPC1759]Posted by rtel on August 7, 2015 If you allocate memory using pvPortMalloc then interrupts will get masked. You can re-enable them manually as long as you are careful that interrupts don't use the scheduler beore it is started.
Regards.
Timers period are affected after allocate memory [LPC1759]Posted by e-christenson on August 9, 2015 I disagree here. My (speculative) diagnosis (based on a dsPIC30F CPU) is that freeRTOS has changed the period register of the timer the LED flasher is using, because freeRTOS is using the same timer for the scheduler.
Another possibility (based on freeRTOSv8.2.1 and the dsPIC) is that the critical section exit in the portMalloc code has enabled other interrupts which are causing the LED flasher to miss interrupts.
Beyond that, this is the point at which knowing exactly how your interrupt controller works and checking on its state (as well as the timer) with the debugger are your friend!
"Use the source, Luke...use the source" (lol)
Timers period are affected after allocate memory [LPC1759]Posted by rtel on August 10, 2015 On a Cortex-M FreeRTOS only tinkers with the SysTick timer (the timer built into the core of the Cortex-M, rather than a periphral). The SysTick timer is not configured until the scheduler is started.
Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|