Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS