2018-12-10 06:09 AM
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
Solved! Go to Solution.
2021-03-03 09:49 AM
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.
2021-03-06 04:31 AM
@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.
2021-03-11 11:59 AM
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)
2021-03-11 02:27 PM
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
2021-03-11 02:45 PM
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...
2021-03-11 02:51 PM
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 ???
2021-03-11 03:47 PM
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
2021-03-11 04:19 PM
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...
2021-03-12 12:01 AM
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.
2021-03-12 02:31 AM
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.