STM32F746 Freeze And Debugger Lost Connection

[SCAN.1]

Hello everyone,

I have a custom board with STM32F746. I'm using STM32CubeIDE for this project.

Board(s) working as expected. But after a while it stops working.

At this point debugger connection also lost. I can not trace anything.

Also ST-Link Utility can't connect to device via Hot-Plug.

It needs to hardware reset for working again.

Is anyone faced something like this?

What i'm missing about debugging?

I'm using SDMMC, Ethernet, FMC, SPI and timer and external interrupts.

Thanks.

[JoniS]

Schematic of the board could help.

Ive done couple stm32xxxx based boards and none of them have had such proplems.​

[SCAN.1]

Hi, thanks for answer.

I'm sure that it is not a hardware problem. Because when i change size of buffers which im using issue disapears.

Its probably my mistake in software. I think mcu enters lockup state. But i cant see anything when it hangs.

[JoniS]

Can you share the code? All of it

[Bob S]

Just a wild guess, but that sounds like memory corruption that may cause errant code to maybe reconfigure the SWI debug pins. Do you have enough stack space? Are you using malloc()? Are you using anywhere near all of the RAM on this chip?

[SCAN.1]

I cant share all of the code sorry. It is a commercial project. I know it is strange i need help and dont share all of the code but it is the situation.

Also project consist almost 60 files except hal and third parties. It will a bit hard to understand what happenning. I just need to know how can i see what happening on mcu.... Thanks.

[SCAN.1]

I'm not using malloc in my code but i'm using lwip for Modbus communication. Fault handlers working as expexted. I tested them but in this stiuation i loose all control.

[Bob S]

To see if altering GPIO is the issue, enable the GPIO locking mechanism (presuming the F476 has that) after you do the initial GPIO configuration. This will prevent stray pointers from altering the configuration of the GPIO pins that are used for SWI.

[SCAN.1]

I tried locking debug pins but nothing changed.

[Piranha]

Another idea - using low-power modes, but not enabling the corresponding bits in DBGMCU_CR register.