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!

[SofLit]

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]

Hello Mohammad,

Thanks for looking into my post. To isolate the issue, I removed the message queue implementation and tried the direct copy through extern variable. But the hardfault hits in a different API now. Any ideas?

Regarding reinit: Sometimes our app doesnt get the UART Rx packets, so I had to reinit to refresh the communication and continue receiving the uart rx packets.

[Mohammad MORADI ESFAHANIASL]

Okay, that is interesting

It seems like the core of the issue is deeper. I suggest creating a project without TouchGFX, focusing only on the UART communication. Focus on receiving sound data from the communication even after restarting the ESP board. If you are able to communicate data after the restart, then it shows that the problem is from the combination of UART and TouchGFX. 

In that case, I think sending trivial data to the GUI while the UART connection restarts might help the issue.

[RiverDi_user]

Hello,

I have tried your suggestion of having a simple application with UART Tx and RX. I tried the update and restart in my ESP board, but I was able to continuously receive the data in the UART without any hardfault issue. I am not sure why having the TouchGfx tasks disrupts the communication and hardfaults. Can you shed some light on this please? DO you have any further suggestion for me to check?

Thanks and Regards

[Mohammad MORADI ESFAHANIASL]

Okay, good to hear the simple application can work with no issues. 

I'm suspicious that waiting for the reestablishment of the UART connection is blocking which causes an error for the TouchGFX tick function (I am not sure about this, but it can be a reason for the error). One possible test could be to handle the UART communication in a separate thread and continuously send data to the GUI (even when the UART connection is lost, just keep sending trivial data) to see if the hardfault persists or not. 

[RiverDi_user]

HI,

I do have the UART Tx in a task and the UART Rx is with interrupt mode. When the UART receives the interrupt, I parse the data and put it in a message queue, eventhough if the UART reinit happens or not, the messagequeue will be holding previous data, but its weird its hardfaulting. I tried to wait in the UART task when there is no Rx data after my ESP reset, but the hardfault hits in a different location like below. FYI, I have removed the reinit logic to test, but the result is still the same.