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 · Accepted solution]

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

This topic has been discussed before, and no, they don't plan on updating the core. The debugging case is a ppm/ppb use case, and doesn't impact product level functionality.

The F722 has a newer core, as do the F76x/77x and H7 parts.

[James Murray]

Thanks for the answer, I did try searching, but perhaps not hard enough.

Shame that the chip won't be fixed as it currently makes debugging very difficult.

James

[Tesla DeLorean]

https://community.st.com/s/question/0D50X00009XkYbhSAF/does-anyone-know-how-to-find-out-the-core-revision-number

[Piranha]

SEGGER have implemented a workaround for this hardware core bug in their J-Link debuggers. On-board ST-LINK can be converted to J-Link OB.

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

[Mario Ghecea]

It does not work in Segger J-Link OB either...Seems once again ST Sold a $70 dollar board without single stepping ability so shifting blame to Segger is a poor implementation of a joke without re-spinning the Silicone...It only works by using the ST Link Utiliy in a special tweaked mode...Open OCD does not work using ST Link or upgrading to Segger. It cannot step as specified above...Single Stepping fails completely in Segger J-Link OB by jumping steps because it cannot stop on a breakpoint and runs hay-wire...Same deal with ST-Link...Sad as it looked like a promising board! Unfortunately it is Junk in any debug mode and I have tried them all...

[Tesla DeLorean]

It is an ARM issue, which they resolved in subsequent spins of their deliverable IP. ST was one of the first companies to get ARM CM7 silicon for them to work with.

ST isn't going to do-over the chip layout and validation, the design team(s) rotated into the next products, it is out of the design cycle, and into the fab/production cycle, and it will be there until end-of-life. Its not a process of constant introspection and correction of a design that's already left the factory.

If you really need to single step your code to understand flow/dynamics then you'll need to pick a part which is a close proxy or use more classical analysis methods.

[Mario Ghecea]

Clive1 - I would love to agree with you but it is a sad manufactured crisis, the story that you concatenated for the unexpected core reset happening suddenly and very unacceptable. The code breaks fine on simple tasks till we get to audio codec work...Then it does not break at all...Do you Mind re-thinking your ugly explanation for selling a broken platform for mass production answer and blaming ARM and perhaps blaming it on work via Audio Codecs ? What IP are you guys protecting exactly and why ???

[James Murray]

I have a workaround that allows me to use breakpoints on STM32F745 with the on-board STlink and OpenOCD.

When you hit the breakpoint:

Step

(lands in an interrupt)

Set Registers -> primask to 1

Run (seems like it didn't do anything)

Step

Continue stepping like normal.

But it is indeed a PITA.

James

[James Murray]

Just to clarify, do you mean F76x/77x or F7x6/7x7 ?

The latter is more in line with the product page: https://www.st.com/en/microcontrollers-microprocessors/stm32f7-series.html (Which I find illogical, the sub-family number would make a lot more sense as the middle number not the final one.)

e.g. F746, F756, F767, F777

James