STM32F746 Cortex-M7 silicon bug. Singlestep lands in interrupt handler

[James Murray]

I'm running into the Cortex M7 r0p0, r0p1 bug where single-stepping is impossible due to the processor handling an interrupt instead.

i.e.

http://www.keil.com/support/docs/3778.htm

I'm using OpenOCD and it is reporting:

Warn : Silicon bug: single stepping will enter pending exception handler!

As per title, this is with an STM32F746Z on a Nucleo 144 which has the bug. STM32F769N worked as expected.

Are there any plans from ST to release a fixed ARM core in the 746 or 745?

regards

James

[Tesla DeLorean]

a) I don't work for ST

b) It's a 5+ year old part

c) This was a 2 year old thread when you posted against it, already citing links at that time where ST indicated in 2017 that this die wasn't going to be respun.

[Piranha]

@James Murray​ , @Mario Ghecea​ 

Guys, the workaround by SEGGER actually works out of the box. I'm using it in EmBitz through J-Link GDB Server with no special configuration and no issues. If it doesn't work, it's probably because of something else. Just a blind guess - OpenOCD.

[Mario Ghecea]

Stop lying and more able people than you have been trying to deceive this thread and this is a known fact that that entire line from ARM had a fault in it probably by design...So save us the BS...What you work for Elon Musk with the fake vids of rockets landing backwards ? Seriously save us the time wasted reading your messages....People here have nested interrupt complex issues not 1+2+3 = (code your wrote)

[James Murray]

How does SEGGER behave if the WWDG is enabled?

My workaround when using OpenOCD doesn't work any more. In my "hit Run" stage it trips the WWDG.

James

[Mario Ghecea]

It does not step period...Don't trust these deceivers from India...It has been admitted as a JTAG stepping bug inside the errata of STM32F746 even by KEIL...

https://developer.arm.com/documentation/ka002944/latest

https://community.st.com/s/question/0D50X0000A4pIcQSQU/stm32f746-cortexm7-silicon-bug-singlestep-lands-in-interrupt-handler

[Mario Ghecea]

Oh another Tesla Fan boy covering the poopies sabotage...In Silicone...Nice excuses...ST Sold that part to millions of customers knowing this issue existed 2 years ago...They need an excuse Pirate like you to apologize for them...How Incompetent of their unscrupulous management to push this forward like that ???

[James Murray]

Did you try the workaround I posted above ? I used that today on a 746 and it works for me (when the WWDG is disabled.)

James

[Mario Ghecea]

KEIL says break your code execution on a breakpoint...

DHCSR -> C_MASKINTS bit while the target is halted and not just for a step

I work on DMA and Audio Drivers...I have never seen such ********...Its a sabotage of the industry sadly...

[SPate.4]

I tried your method. I noticed that when I set the PRIMASK bit, I run into a TIM IRQ when single stepping after I declare a thread. When I don't set the PRIMASK bit, I run into the TIM IRQ when I run System Clock Config. When you were able to solve this issue, were using threads?

PS: I am not using WWDG.

[James Murray]

I'm not using threads. My application is a single core with no RTOS.

If you do hit another interrupt, re-check PRIMASK is set and hit "Run" again. Hopefully you end up at your breakpoint in the end and can step from there.

That's my experience anyway. I'm not sure I understand how any threads or RTOS behaviour could really change this very low-level behaviour of the core? (But could be wrong!)

James

PS. I'm not entering the flame-war about "Clive" as he has provided plenty of useful information on this forum.