32F746GDISCOVERY: help with the hard fault handler

[Jackiii1989]

Hi,

I am developing an application on the 32F746GDISCOVERY board. The application reads data from a Python script that send certain strings to the MCU via USB connected to the USART1. The data from USART1 is then passed through the queue to the Screen1View where it is displayed in the TextArea field. Once this is done, the MCU sends a reply back to the "Python script" and then a new command is executed.

The application runs fine for some time, but after a few seconds, the hard fault handler is called. Here is the function stack:

I currently do not know what is located at the address 0x30302d32. Does anyone have any insights on this?

Also looking at the memory map, the address 0xffffffed is associated with the Cortex M7 internal registers and there should not be a function call to it, right?

I have found a relatively similar post about this here, but it suggests increasing the stack size. Looking in the stack size of the task the default value is 4096 bytes, which is more then enough of memory I would say.

Can anyone help me with this? Thanks in advance.

[GaetanGodart]

Hello @Jackiii1989 ,

7z should be accepted.

"The file type (.touchgfx) is not supported. Valid file types are: ai, avi, mp4, bmp, csv, doc, docx, flv, gif, ico, jpg, jpeg, log, mov, mpg, mpeg, mp3, odt, odp, ods, pdf, png, pps, ppt, pptx, rar, rm, tif, tiff, txt, xlr, xls, xlsx, xml, wmv, wav, z, 7z, ioc, hex, c, cc, cpp, h, hpp, tar, xz, dts."

Regards,

[Jackiii1989]

Hi @GaetanGodart,

Sorry for my late reply. I have been quite busy with the rest of my life.

I managed to upload the project to the chat, which is amazing from my point of view. I also succeeded in making it work. At least it no longer crashes. However, I would appreciate it if you or anyone could take a look at the code and give me your thoughts and comments. Are there any code smells or other problems you see? Thanks

I also need to adjust the stack as it is now too big. Just to let you know in case you are surprised by the size of the stack.

As @waclawek.jan and @Tesla DeLorean  pointed out that I was defining too much memory or trashing the stack, which caused the static queue buffer to change pointing to a strange address. When the FreeRTOS queue API used memcpy to transfer data, the hard fault was thrown. I probably overwrote the queue control block. I was not aware of how deep I was on the stack.

This is my explanation. Please correct me if I am wrong.

Thanks all for the help and the input.