STM32 OSMessageQueue Hardfault error

[RiverDi_user]

Hello,

 

I am using a RIverDI STM32U5A9 and I am facing a strange hardfault issue in my environment.

The connection details as follows:

ESP board <--UART--> STM32 <--MessageQueue---> LCD display

The ESP board sends continuous data through UART and the STM32 UART task receives the data and send the data to LCD display task through message queue. Whenever I try to restart the ESP after firmware update, the STM32 stops getting UART data and reinit the UART once the connection is reestablished. But the application gets into hardfault error when this happens. The hardfault occurs after few packats transfer and not on the first UART reception.

Can someone help me on this?

 

Thanks!

 

[mƎALLEm]

Hello @RiverDi_user ,

Your use case is a bit tricky and not possible to help you with this description. 

You need to provide more details about your code implementation. Share your code etc ..

[Mohammad MORADI ESFAHANIASL]

Hello @RiverDi_user,

Could you please share how you are dealing with the received packets in your application?  

[RiverDi_user]

Hello,

 

Unfortunately I cant share my code since its proprietary, but I can give you the logic that I am using in my code.

I am using a RiverDI 5 inch display development module, which is having STM32 embedded in it. I am also using TouchGFX to program the 5 inch display. Basically my riverDI application contains multiple tasks, one for receiving the UART from the ESP board and one for updating the display through touchgfx APIs. To share the received UART data between my UART task and touchgfx task, I am using a message queue, where the UART task puts the data in the message queue once UART Rx is received from ESP and TouchGfx task gets the data every ticks (1ms) and displays in the screen.

UART task snippet (when the UARTRx is received):

TouchGfx task snippet:

The hardfault is occurring in the subsequent calls of osMessageQueueGet() as I shared in my previous comment.

 

Regards!

 

[Mohammad MORADI ESFAHANIASL]

Thanks for sharing more information.

The values for osMessagesWaiting and osLength do not look reasonable. Since UART is asynchronous, I don't understand why a reinitialization is required by STM32. The connection should just wait for data no matter the sender. Anyway, I suggest clearing the queue after the UART reestablishment.

In addition, it is better to deal with UART errors before sending any data to the GUI to ensure the TouchGFX thread will not be blocked.

[RiverDi_user]

I was able to findout the rootcause and it was before the osMessageQueue. The issue is fixed now after I checked the buffer index which was exceeding the allocated buffer limit.

 

Thanks everyone for your replies!