ST Link V2 doesn't connect the target after 1~3 times firmware download.(STM32G071R8T6)

[unmo]

Hi.

I want to use ST32G071R8T6 on my project.

As a first step, I was testing my firmware on NUCLOE-G071RB (that connected indivisual st-link board).

I was no problems and working well.

​However, on the board I made, it behaves abnormally.

​ST Link V2 doesn't forget the target after 1~3 times firmware download.

Has anyone ever experienced these symptoms or knows how to fix them?

I changed boot0 pin to pull-up​, but the ST Link V2 didn't connect to target also.

Please give me an idea.

Thanks.

[waclawek.jan]

Inadequate power supply/decoupling?

Too long SWD cable with inadequate returns (ground/DC leads)?

Ground loop/grounding problems?

JW

[Uwe Bonnes]

Device in long or deep sleep. Connect under reset choosen?

[unmo]

I used the power source that 3.3V DC through the regulator.

I will check the ground problems.

Thanks.

[unmo]

Thanks for your reply.

I applied under reset mode, but the result was same.

What can I check other point?

[Alexandre Meyer]

I've just experienced the exact same problem. Started a new project with a ST32G070KBT6 and, after the first download, all programming attempts returned "No device found on target".

The device was NOT sleeping nor reset. Led was blinking while it refused to respond.

My SWD cable was fine, It worked at the first download and I use it regularly with an STM32F4 on another project.

After locking myself out of two prototypes I found that, in the .ioc editor, the SERIAL WIRE flag must be checked in System Core >> SYS Mode and Configuration.

 

It is my first project using STM32cubeIDE. My previous designs used STM32cube + Atollic True Studio and never had this issue.

In my opinion, since this is the only debug interface available to this device family, this flag should be set by default. Anyway...

I hope it helps.

Good luck.

[Andreas Bolsch]

Don't recall right now in which document this was mentioned: On the G0 it's strongly advisable to a have a substancial delay at startup *before* any port initialization. Because if NRST had been configured (be it deliberately or accidentally) to become ordinary GPIO, there is almost no chance for a debugger to connect before possible reassignment of SWD pins for other use: 'Connect under reset' won't work in that case. Same problem (and same recommendation) as for some low pin-count STM8 devices ...