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.

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.

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.

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.

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)

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.