xStreamBufferReceive blocking on highest priority task

JacobApium · July 7, 2022, 6:34am

I have this setup that is doing next to nothing. I have one task per direction (bridgeToRadio and radioToBridge) so that I can block while I’m waiting for data to come in.

My ISR uses xStreamBufferSendFromISR() minding the xHigherPriorityTaskWoken return result per FreeRTOS documentation. My highest priority task (bridgeToRadio) is blocking on xStreamBufferReceive with portMAX_DELAY. I’m expecting that the ISR will exit and return to the highest priority task that was previously blocked. However the time it takes is between 300us to 6000us as seen on my Oscilloscope for received data to be transmitted. All of the other tasks spend most of there time blocked on a vTaskDelay() or vTaskDelayUntil(). The concern is not so much the 6000us delay but more that some data is re-transmitted then it appears that a context switches ares happening (because the StreamBuffer has been emptied and the task is blocking again). My impression from the xStreamBufferSendFromISR() documentation is that my high priority task should be getting all the attention as long as there is data in the StreamBuffer.

I have one simple question, is my understanding correct here that my high task should run as long as there is data in the StreamBuffer?

CH3 (Pink) incoming data to STM32, CH1 (Yellow) output data from STM32, CH2 (Cyan) received data at other radio.

My queue trigger levels are set to 1. The system clock is running at 90MHz on an STM32. My tick rate is 1000 Hz.

------------------------------------------------------------------------------------------
                                        TASK REPORT  
------------------------------------------------------------------------------------------
order   number          name            pri     stack   time               cpu  state
0       5            monitorPortTask    1       1280    711               0.02  Running  
1       6                       IDLE    0       1004    2878790          98.83  Ready    
2       1                defaultTask    3       4023    3591              0.12  Blocked  
3       4             sdmmcWriteTask    2       998     882               0.03  Blocked  
4       2              bridgeToRadio    5       971     28300             0.97  Blocked  
5       3              radioToBridge    4       973     451               0.02  Blocked  
------------------------------------------------------------------------------------------
Total Run Time: 2912752 
TotalHeapSize           = 0x00012000
CurrentHeapFree         = 0x00006CA0
MinumumEverFreeHeapSize = 0x00006CA0
MaximumEverUsedHeapSize = 0x0000B360

htibosch · July 7, 2022, 6:49am

@JacobApium, before answering, would you mind to post two pieces of code: both the ISR and the highest-priority task were it calls xStreamBufferReceive()?
Thank you

aggarg · July 7, 2022, 9:50am

Yes - as long as your ISR is not running, the highest priority ready task should be running.

This description is not clear. Would you please elaborate. Also, please post code snippets as suggested by Hein.

JacobApium · July 7, 2022, 4:55pm

Thanks both… I’ll work on paring the code down so that it is easily digestible and shareable. Its littered with DMA and custom fifo’s and serial classes. I may even solve this on my own in the process.

Jacob

JacobApium · July 7, 2022, 9:04pm

I’m getting closer. The big issue seems to be that the previous dev turned on the USART Rx DMA. The DMA had to fill up before the interrupt would fire and the packet length being transmitted is not an integer multiple of the DMA buffer so some beating was occurring (this was causing the 300us-6000us delay). The timing is very consistent now at 380us.

Here is an updated trace. It appears that I’m dropping data because the cyan trace should match the pink trace (but there is less data there). I hate it when this happens but I think I need to read the datasheet to better understand the STM32 USARTS work.

CH3 (Pink) incoming data to STM32, CH1 (Yellow) output data from STM32, CH2 (Cyan) received data at other radio, CH4 (Blue) low=task blocked, high=task running.

Jacob

JacobApium · July 7, 2022, 11:51pm

Resolved it. It seems that the major issue was the Rx DMA buffer size beating against the packet size. I think the lost data from the last post was a baud rate mis-configuration on one of the ports.

CH3 (Pink) incoming data to STM32, CH1 (Yellow) output data from STM32, CH2 (Cyan) received data at other radio, CH4 (Blue) high=task blocked, low=task running.

rtel · July 8, 2022, 12:55am

Thanks for taking the time to report back.