rtel wrote on Tuesday, February 18, 2014:
[I like the way you have included source code in your post - very easy to read. I **really** wish SourceForge would just format code between <code> tags automatically as well as you have done it in your html].
First, I’m not sure 100% that I understand exactly the problem, but do think from a first read that it is not a FreeRTOS problem as your code looks basically ok. It is much more likely to be a hardware management problem (how and when interrupts are triggered, when and how to enable/disable interrupts etc. are all hardware specific and outside the scope of this forum).
Where is the character actually read form the UART? Your code does not show the character being removed from the UART’s Rx buffer, which probably means that each time you leave the interrupt the interrupt will immediately get asserted again because there is still data waiting to be read.
I would recommend replacing the for() loop null delay with a vTaskDelay() call because that will give it a definitive delay time, rather than a delay that will change depending on how fast the clock is and which other tasks are running in the mean time. Also it will allow other tasks to run during the delay period. One final reason - as soon as you turn optimisation on the whole delay loop will get optimised away because your variable ‘l’ is not declared volatile.
Have you taken note of all the items on this page: http://www.freertos.org/RTOS-Cortex-M3-M4.html regarding interrupt priorities, especially the bits in bold red text that are specific to the STM32? As you are using V7.6.0 ensuring configASSERT() is defined will help trap a lot of the pits that are easy to fall into.
You don’t need to test xHigherPriorityTaskWoken yourself, the test is included inside the portEND_SWITCHING_ISR() macro.
Are you trying to write to the screen on each character that is received? Writing to the screen will take mane thousands of times longer than the time taken to receive each character.