connecting SWO pin is causing Hard Fault Exception(unaligned memory access)

[LZhan.1]

Hi,

I got a strange behavior during debugging my bare metal application on STM32F745ZGTx. The emulator is ST-Link V2, with "B 2018 02" printed on the back. The Hard Fault exception (unaligned memory access) is triggered randomly. I mean, the PC causing problem is not at the same place, but randomly. The trouble-shooting steps I have taken:

1. Originally I suspect it is related to the power supply or PLL clock. So I enabled the Brown-out reset and switched to internal HSI. But the problem is still there.
2. Then I suspect the IDE. I tried both Keil and IAR. The problem is seen on both IDEs.
3. I upgraded my ST-link firmware. The issue is still there.
4. Removing SWO connection, but keep the source intact, and keep the SWDIO/SWCLK. This time, the problem is gone.

So it seems the SWO connection is causing the problem. But I am sure the connection is fine, as I can saw the printf content when SWO is connected.

Do you have any idea about the problem? Please see the attached pictures for the crash, and the attached ioc file for my configuration. Thanks in advance.

BR

/Li

Add one more point: I tried to disable the ITM redirect IO and disabled the printf code directly. In such case, if the SWO pin from ST-Link V2 is still connected to the target, the problem will rise too.

[Tesla DeLorean]

I'd probably look at the stack allocation and usage

[LZhan.1]

Hi,

Thank you for your quick answer. I have worried about the stack originally. So I expand the Stack to 0x4000. Here is the allocation in map file:

  STACK                  0x20001380  Section  16384 startup_stm32f745xx.o(STACK)

Attached is the picture for the stack content. There seems no overflow.

BR

/Li

[davideo]

I also have the same problem.

For me, SWO is always connected, but the hard faults start randomly ocurring when enabling an SWO function like Interrupt log in IAR. Disabling the Interrupt log does not make them stop. I must power cycle the STM32H743 then reconnect. Does the SWO function interfere with CPU operation?

[Tesla DeLorean]

>>Does the SWO function interfere with CPU operation?

It doesn't

There's some other latent issue that you're now observing. Where exactly is going to be harder to pin down.

It uses PB3, and the debugger is changing setting to some internal hw to facilitate this, so DWT, ITM and in H7 some funnelling.

So you've got the debugger probing, and you're buffering / waiting on the STM32 side. The debugger is often more invasive that people think, because it's using the same mechanics as the user to access things, so it contends, or messes with peripheral registers or FIFOs, etc

Perhaps use secondary/alternate methods to output telemetry, say a USART and buffering, so that it doesn't distort the time-line when you're outputting.

Output as much data as possible in the HardFault_Handler()

Have things which monitor stack, usage, high/low water marks, walk the heap, etc.

The H7 has to be power cycled, often, because it latches thing, and NRST doesn't do a complete chip level reset. Some of this relates to latching BOOT and OPTION BYTES, and as a means to thwart attack vectors.

Use alternate tools, say ST-LINK and STM32 Cube Programmer, or Segger J-LINK, and see if the problems follow, or if it's more with the implementation you're using.

[davideo]

Mr Delorean,

Thanks for all the suggestions! I'll try to debug the intermittent hard fault.Fun fun.
Do you think there an issue with my code which is being exposed because SWO is affecting:

a. CPU timing whcih would affect task timing?(I'm using an RTOS)
b. CPU registers?
c. CPU memory?

But if SWO doesn't affect CPU operation at all I don't get how it can be happening.
Same problem happens with either ST-LINK or J-Link.
I don't use the SW pins for anything else.
Thanks,

Dave

[Chris21]

Printf can use significant stack space in embedded applications, potentially leading to overflow.

You stated that disabling the printf calls did not resolve the issue.  Are you sure they were all disabled?  Obviously, one experiment you could try would be to double the size of all your task stacks, or at least the ones calling printf or similar functions.

[Tesla DeLorean]

+1

Yes, and the serialization that occurs when sending long character streams via the ITM_SendChar() channel.

At the least disruptive level I'd tend toward sending single characters to gate-post/check-point execution.

This would also be a situation where TRACE would be useful at working the failure point backward.

Yes, use the stack sizes as a method of bisection and containment.

ARM doesn't have a good stack-check function, or compilation level on/off switch for it. But one can use strategic fill pattern checking for high/low water marking.

[davideo]

I thought perhaps the xPortPendSVHandler was being interrupted by a higher priority interrupt, but I have reduced all code execution down to just the IdleTask and the SysTick interrupt as shown here in the Interrupt log:

...

21s 866820.48 us SysTick Leave ---- 0.67 us
21s 867819.79 us SysTick Enter ----
21s 867820.46 us SysTick Leave ---- 0.67 us
21s 868819.78 us SysTick Enter ----
21s 868820.45 us SysTick Leave ---- 0.67 us
21s 869819.76 us SysTick Enter ----
21s 869820.42 us SysTick Leave ---- 0.66 us
21s 870055.88 us HardFault Enter ----

I'm not using printf. The original poster LZhan.1 is.