STM32H745 crashes after running for some time

[HKapo.2]

Hello All,

We have been stuck with this particular issue for more than a month.

For STM32H745, we have enabled only cortex M7 and it has freertos with some logic using a math library.

The code runs for some time (between 30 minutes and 2 hour) and gets a hard fault.

Looking at debugger it states that a "new" operation was called and it failed due to out of memory.

We use __heapstats() in a background task which runs every one second.

It doesn't show any leak in the memory as the free heap remains the same.

Has anyone faced similar issues?

Any pointers is deeply appreciated.

[Tesla DeLorean]

I think most of us have had to debug things of varying levels of complexity.

Determine which "new" operation failed.

Instrument code, add sanity checks, and try to understand the flow dynamics immediately before failure.

Not sure if the system is set up for trace connectivity, or if you can port to a platform or proxy for your system that you can. https://www.pdqlogic.com/

Instrument the allocator, see what size of allocation fails.

If you have a functioning heap with free space, likely some corruption in a structure, or size of something it's attempting to copy.

I generally have a Hard Fault Handler that dumps internal registers, state, and stack, and we try to unpick things from there, adding checks to try and pin point the failure, and work backward to the cause.

[HKapo.2]

Like I mentioned before, we are using __heapstats to monitor the heap and there is no memory leak.

We have also integrated Segger's RTT and monitor the task using System View and there is nothing out of ordinary.

It doesn't fail at one location, during several run it failed in different places and all it is requesting is 24 (or something similar) bytes of data.

[Bob S]

Sounds like memory corruption if the heap has "lots" of available memory but fails on a request for 24 bytes.

Is access to the memory allocation functions properly mutexed/single-threaded? Do you have the malloc/new allocators going through the FreeRTOS heap functions or the separate (standard) c/c++ heap?

Caching issues?

[Tesla DeLorean]

Ok but if you analyzed and walked the heap why can't you see why the new/constructor failed to find a large enough block of linear memory.

Too fragmented? Completely full? Allocation too large?​

[HKapo.2 · Accepted solution]

OK so I added --no_unaligned_access in misc control option for keil and the problem is not there any more.

We ran the firmware overnight (12 hours) and it didn't crash.

However we are baffled as how this has fixed the issue. There is no external RAM in use.

Any clue?