STSPIN43G Debug info: Break at address "0x1fff4b14" with no debug information available, or outside of program code.

[kkuan.1]

Dear,

We are using the STSPIN43G4 to drive brushless motor, we have debuged in the evaluation board successfully, now we have made our board, but when we debug, it should the following info: Break at address "0x1fff4b14" with no debug information available, or outside of program code.

And during debug we even found that the software didn't go to SysTick_Handler function too.

We have checked our hardware design, we didn't find difference with the evaluation board.

Thanks.

[Tesla DeLorean]

Sounds like its booting into ROM, so the mapping at zero is the ROM, and the Vector Table is pulling from there too.

It could be because the FLASH was blank at the last power cycle, or that the BOOT0 setting was High.

There's perhaps a FLASH flag, perhaps OPTVERR?? or something similar on the G4. Perhaps need to clear that

[waclawek.jan]

Interesting, there's no public information about STSPIN43G anywhere... So who knows what's its core.

My guess based on naming is, that it's the STM32G4xx. If it's 'G47xx with AN2606 bootloader activation pattern 14, that includes the "empty FLASH" check, so I'd recommend start with a power-off-on cycle after the first programming.

JW

[kkuan.1]

Thank you for your help.

I have changed the Option Bytes using STM32 ST-LINK Utility, and de-select the nSWBOOT0, the debug info was disappeared, but the software seems still work abnormally.

[kkuan.1]

Thank you for your help.

The core of G4 was G431.

I have changed the Option Bytes using STM32 ST-LINK Utility, and de-select the nSWBOOT0, the debug info was disappeared, but the software seems still work abnormally.

[waclawek.jan]

> The core of G4 was G431.

Thanks for the clarification.

> software seems still work abnormally.

There's probably no other way than to debug as usually, i.e. find out the reasons why software behaves differently than expected, by experimentation and observation.

JW

[MBorg.4]

TLDR; Check if conductive stuff like no-clean flux residues is shorting pins on your hardware.

I'm sure OP found a solution to his problem, but I'll post the solution I found for people who might stumble into the same issue.

I got the same error message (0x1fff4b14) after having soldered on my fully functioning board (based on an STM32G431). The day after, I realized that I had used lots of no-clean flux (which apparently is conductive) during the soldering process. This left many pins on the STM32 gunked up, which probably shorted some of them. For example, the BOOT0-pin was all of a sudden pulled high (should be low in my case) by having been shorted to a nearby VCC-pin on the MCU.

I re-soldered all the pins by shortly heating up each leg and thus removing the solder residues (could also be done with flux cleaner). After this procedure, the MCU was up and running again!

Hope this help someone else who might be fiddling with functional hardware 😅

/MB