Task, blocked waiting for message, stops getting serviced.

Kernel
1

ddeyo wrote on Friday, August 23, 2019:

I have a task that is blocked on xQueueReceive, every 5 secs.
Normally, this task will get unblocked when a message gets sent to the task’s queue.
However, every once and a while, the queue stops looking for messages.

The messages are being sent from three different gpio ISR’s. I am using the prescribed method xQueueSendToBackFromISR to send to the queue in the task.

Is it possible that one of the ISR’s are causing the task to removed from some list, thereby preventing it’s
queue from getting serviced?

2

richard_damon wrote on Friday, August 23, 2019:

From what you have said, the most likely issue is that some ISR has a priority too high for FreeRTOS. (and if the processor is an Arm Cortex, that means too low of a value).

One quick test is to make sure you have defined the configASSERT macro to halt the processor in a way you can check with a debuggger. If you are running a recent version of FreeRTOS it will check for this and trap on it.

3

ddeyo wrote on Friday, August 23, 2019:

p.s.

My test is spoofing gpio isr messages from a task, while generating real messages from a gpio interrupt.
This tends to cause what appears to be the same error condition from gpio interrupts alone.

-dwd

4

ddeyo wrote on Saturday, August 24, 2019:

Thanks for answering Richard,

I believe the macro is defined. The core halted, early on, because I had the priority of the gpio interrupts(3 pins) set at 0. Setting the priority to 5 allowed msg’s to be sent.

Under a gpio interrupt load (3 gpio’s firing within ms of each other, both high and low), the gpio task stops calling xQueueReceive and the queue fills up.

The size of the queue doesn’t seem to matter.

I can see where occasionally, while trying to force the error to occur, a msg from an interrupt occurs when the scheduler is suspended.

In task.c, is says that this TCB gets stuck at the end of the list until the scheduler is resumed.

Is it possible that multiple interrupts accessing the same TCB could confuse the state of that TCB to end up without a task to be un-blocked but with a full queue?

-dwd

5

aggarg-aws wrote on Monday, August 26, 2019:

How are you determining that the task is not unblocked? Is it possible that ISRs are firing too quickly and the task is not getting a chance to run? Would you be able to share your code?

You can read more about the setting interrupt priorities in Cortex-M while running FreeRTOS here: https://www.freertos.org/RTOS-Cortex-M3-M4.html

Thanks.

6

ddeyo wrote on Tuesday, August 27, 2019:

Thanks Gaurav,

I figured the task was not getting un-blocked by making the timeout 5 seconds.
Under normal operation, if no message was received in 5, I would hit the breakpoint again.

After a few gpio interrupts(? 3-4), the task stops hitting the breakpoint, even when I induce a gpio interrupt with a pulse generator.

When I see the problem, the only interrupt I see firing is the systick.

I have inadvertently found the problem, not the root cause though.

I had a second task to buffer messages; if I received new interrupts before I had time to respond to the old ones.
In that second task, I again had a ‘wait until ready condition’ that used an osDelay and a re-transmission of that message to itself.
With only a few messages, it broke some component of the messaging/scheduler task. What I had read (in one of the task.c comments) said that an interrupt while
the scheduler is paused could cause a task to be removed from one of the lists, either the ready or pending.

For now, I’m buffering the messages and processing that buffer, once the time is right.
Sounds like I found a bad way to use messaging.

-dwd

From: Gaurav Aggarwal aggarg-aws@users.sourceforge.net
Sent: Monday, August 26, 2019 5:09:37 PM
To: [freertos:discussion] 382005@discussion.freertos.p.re.sourceforge.net
Subject: [freertos:discussion] Re: Task, blocked waiting for message, stops getting serviced.

How are you determining that the task is not unblocked? Is it possible that ISRs are firing too quickly and the task is not getting a chance to run? Would you be able to share your code?

You can read more about the setting interrupt priorities in Cortex-M while running FreeRTOS here: https://www.freertos.org/RTOS-Cortex-M3-M4.html

Thanks.

Task, blocked waiting for message, stops getting serviced.https://sourceforge.net/p/freertos/discussion/382005/thread/d8d37dafc2/?limit=25#ff23/b09e/c057

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/subscriptions/

7

aggarg-aws wrote on Wednesday, August 28, 2019:

The fact that the task is not getting unblocked indicates towards some issue. If you can share the project/code which demonstrates the problem (after removing the proprietary code, if any), it will be easier for me to debug. Which hardware platform are you using?

Thanks.