FreeRTOS task is not running though Timer ISR

This topic was lost when the forum software was switched back to the old version.  I am pasting the entire thread below as a single post so it does not get lost.

FreeRTOS task is not running though Timer ISR

I have developed firmware for ARM-CM3, STM32F103RE board in IAR Embedded workbench using FreeRTOS. Communication with the board is possible in two ways, USB & USART (RN-42 Bluetooth module). There are only two tasks( excluding IDLE task) in the firmware and they are synchronized:
Data Task (DT) : Responsible to collect data from MEMS sensors & process using some algorithms and send the data to USB & USART2.
Command Task(CT): Responsible to decode the commands or data received from GUI application located in Computer. To trigger the DT, Timer2 ISR (runs at 100Hz) has the following code. When device is streaming data to PC GUI via Bluetooth module which is connected to USART2, some times the streaming stops( DT not being executed), even the Timer2 ISR is still running. After the streaming stops, if I send any commands to board via USB or Bluetooth, they are received by the board and decoded by CT properly. Note: If I connect to board via USB, this problems not occuring.
For the complete debug information i wrote a detail article on my blog: http://harinadha.wordpress.com/2012/10/16/misterious-bug-freertos-task/
It was hard for posting such big debug info here, so wrote there. Please do not mind.
Thank you. Reply
Link
Edit
Delete
Attach Richard
2 days ago
First off, the usual links apply, and I have to ask if you have your interrupt priorities set correctly. If they are incorrect you may get data corruption that leaves a task in the wrong state, and so preventing the scheduler from running it:
http://www.freertos.org/RTOS-Cortex-M3-M4.html
http://www.freertos.org/FAQHelp.html
If I understand correctly, you are using a UART to connect to a bluetooth module. Is it the UART to the bluetooth module that is no longer streaming data, or is data going to the bluetooth module from the UART, but the bluetooth module is not processing the data?
Also, if I understand correctly, you have a timer that is triggering a task using a semaphore (looking at your code). The use of the semaphore looks ok. At some point, the timer is still executing, but the task does not appear to be running. Is the task still being unblocked by the semaphore, but then apparently not doing anything, or is the task never running at all. If the task is never running at all, what is the task doing? (i.e. if it is not blocked on the semaphore waiting to execute when the timer gives the semaphore, what is it executing or trying to execute).
Regards. Reply
Link
Edit
Delete
Attach hari
2 days ago
Thank you Richard for quick reply. I updated more Debug info at my blog post, please read. Find section Latest Debug Info.
As I said the responsibility of the DT is to collect data from MEMS sensors through I2C & then process the data. At some random point of time when the board is connected via Bluetooth, a while() loop inside I2C read becoming infinite. Since execution could not come out of DT, even the timer2 is firing DT, my previous breakpoints could not catch the trapped location inside DT code. Because of this, even i stopped the timer, still the DT status is RUNNING. The images show where the execution trapped, Tasks status and CSTACK.
I really do not understand why the problem occurring only when communicated via Bluetooth ? Why at random times ?
Regarding interrupt priorities:
Please go through the FreeRTOSConfi.h in the blog post.
I have the following ISR’s in my firmware:
1. Timer2 ISR for triggering Data Task(DT)
2. USART2 ISR for communicating with USART bluetooth module
3. EXTI15_10 ISR for 3 buttons
Please find the attached file for other ISR’s.
Thank you
 
Last edit: hari 2 days ago
Attachments
stm32f10x_it.c Reply
Link
Edit
Delete
Attach Erupter
2 days ago
No matter what infinite loops you encounter, if the taks is well
designed -that is it follows the guidelines- it will be able to be
preempted and shuffled by the kernel.
I strongly suggest you test your I2C library in a standard
non-multitasked program, and do a deep debug on that.
If it stucks in a thread, it will stuck by itself too.
Once you have debugged that, you can make a task implementation.
Also I strongly encourage you to abstract the library as much as
possible and use interrupts.
If you already use interrupts for your I2C: have you added those
interrupts to the kernel?
Is the kernel aware of the I2C interrupts?
Have you coded them with the correct priority?
Also please note the mailing list does not accept attachments.
Regards
Claudio
On 10/17/2012 01:45 PM, hari wrote:
s I said the responsibility of the DT is to collect data from MEMS
sensors through I2C & then process the data. At some random point of
time when the board is connected via Bluetooth, a while() loop inside
I2C read becoming infinite. Since execution could not come out of DT,
even the timer2 is firing DT, my previous breakpoints could not catch
the trapped location inside DT code. Because of this, even i stopped
the timer, still the DT status is RUNNING. The following images show
where the execution trapped, Tasks status and CSTACK
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/freertos/discussion/382005/
To unsubscribe from further messages, please visit
https://sourceforge.net/auth/prefs/ Reply
Link
Edit
Delete
Attach Richard
2 days ago
Your code is getting stuck in:
    while( !I2C_CheckEvent() )
so it is not clear why you think this is a FreeRTOS problem. Is you I2C driver handling all error conditions, like arbitration lost? Does it have a recovery mechanism?
Please go through the FreeRTOSConfi.h in the blog post.
It is not for me to go through your code, besides which FreeRTOSConfig.h does not set the priorities of you peripheral interrupts.
Are you setting the priorities, and are you setting them to a priority at or below configMAX_SYSCALL_INTERRUPT priority as per the documentation page I provided a link to.
Also, as you are using an STM32, are you calling NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 ); to ensure all the priority bits are set as pre-emption priority bits?
Regards. Reply
Link
Edit
Delete
Attach hari
2 days ago
@ Richard,
I did not mean “look at my I2C code” as it is not related to FreeRTOS, but i found this problem while i have been working on this thread & my Debugging in parallel. So i wanted this thread to be complete solution for the problem.
This is first time I’m working with RTOS, so really like to learn deeper.
I placed taskENTER_CRITICAL() & taskEXIT_CRITICAL() in I2C read & write functions. Actually my other I2C libraries have these critical sections (I forgot to place them in these 2 functions). Now there are no traps in DT.
But i started getting new problem:
When I send connect/disconnect commands(5 bytes data) to the board via Bluetooth, after some repeated times, though the USART2 ISR receives data successfully, CT not raised even the following code in ISR fires it.
if(rxByteCount != 0 )
{
portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE; Ctype = Bluetooth;
xQueueSendFromISR(s_usbQueue, &rxByteCount, &xHigherPriorityTaskWoken);
rxByteCount=0; portEND_SWITCHING_ISR(xHigherPriorityTaskWoken);
}
The FreeRTOS task status window shows CT is RUNNING, DT is READY & IDLE Task is READY.
Yes, I’m calling NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );
Is it a good idea to trigger one task from two different ISR’s ?
Thank you.
 
Last edit: hari 1 day ago
Reply
Link
Edit
Delete
Attach hari
1 day ago
Debug Info for the new problem stated above is explained below.
The CT is not fired though ISR executes the above code listing is because the FreeRTOS API function xQueueSendFromISR(s_usbQueue, &rxByteCount, &xHigherPriorityTaskWoken); is returning xReturn = errQUEUE_FULL;
CSTACK for the break point:
I do not understand why the Queue is full. I used the following code to create queue:
// Create the queue used to synchronize Command Manager task end USB ISR or //USART2 ISR.
s_usbQueue = xQueueCreate(1, sizeof(u32));
if (!s_usbQueue)
{
// Error in resource creation.
while (1);
}
Thanks for reading such a long description of the problem.
 
Last edit: hari 1 day ago
Reply
Link
Edit
Delete
Attach Dave
1 day ago
Someone asked
Are you setting the priorities, and are you setting them to a priority at or below
configMAX_SYSCALL_INTERRUPT priority as per the documentation page I provided a link to.
Also, as you are using an STM32, are you calling NVIC_PriorityGroupConfig(
NVIC_PriorityGroup_4 ); to ensure all the priority bits are set as pre-emption priority bits? Reply
Link
Edit
Delete
Attach hari
1 day ago
I replied for Richard:
Yes, I’m calling NVIC_PriorityGroupConfig( NVIC_PriorityGroup_4 );
My USART2 interrupts are configured as below:
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 6;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0;
I have set configMAX_SYSCALL_INTERRUPT 191
Is this ok ?
Thank you Reply
Link
Edit
Delete
Attach Richard
1 day ago
As per the link posted in my first reply (it wan’t me that made the Cortex interrupts so complex!):
The STM32 implements four priority bits, so the lowest priority is 15. The top four bits of 191 (decimal) are 1011 (binary), which equals 11 (decimal). Therefore, interrupts that use the FreeRTOS API must have a logical priority of 11 or lower. On the Cortex-M3, lower priority means higher numeric value, so if you are using the API from your USART, then it must have a priority between 11 and 15 inclusive.
Conclusion – your configuration is not valid and you need to either change the priority of the USART interrupt or the value of configMAX_SYSCALL_INTERRUPT_PRIORITY.
Regards. Reply
Link
Edit
Delete
Attach hari
1 day ago
Hi Richard,
Thank you for explaining me in detail as i did not understand this earlier. MY PROBLEM IS SOLVED. I’m very thankful to you.
In my entire firmware i have 6 interrupts now:
1. Timer2 : NVIC_IRQChannelPreemptionPriority = 10;
2. USB : NVIC_IRQChannelPreemptionPriority = 11;
3. USART2 : NVIC_IRQChannelPreemptionPriority = 12;
EXTI15_10 ISR is used for 3 Buttons:
4. Button1: NVIC_IRQChannelPreemptionPriority = 13;
5. Button2: NVIC_IRQChannelPreemptionPriority = 14;
6. Button3: NVIC_IRQChannelPreemptionPriority = 15;
If i understood correctly, Button3 has lower logical priority than Button2. For these interrupts, I have changed the following FreeRTOSConfig.h
configMAX_SYSCALL_INTERRUPT_PRIORITY 159; The top 4 bits are 1001(binary), which equals 9(decimal). With this modification, I can use the numbers between 9 and 15 inclusive. Which means 10,11,12,13,14,15.
Richard, thank you for your patience to go through my long debug info which was mostly non relevant( I2C, USART etc..).
What should be the value for configMAX_PRIORITIES now? Is it 6 ?
Thank you again.
Hari