EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: tariq on April 13, 2021, 07:23:58 pm
-
hello every one
I'm using stm32f101vbt6 by st-linkv2 programmer.
after few times programming my micro i get this message : no target connected. so my debugger can't recognize microcontroller.
i checked every connection and its ok. so i changed micro and programmed micro few times and this problem happend again for three times.
in my pcb design i connect SWDIO from programmer to micro and between them i put 330 ohm resistor.same thing for SWCLK as the picture uploaded.
in my board when programming i'm connect my power plug on from adapter
i don't know why this happening.is it because of ESD(Electrostatic Discharge)?Is my design has any problems?
i didn't have this problem for stm32f103.
appreciate your help.
-
hello every one
I'm using stm32f101vbt6 by st-linkv2 programmer.
after few times programming my micro i get this message : no target connected. so my debugger can't recognize microcontroller.
i checked every connection and its ok. so i changed micro and programmed micro few times and this problem happend again for three times.
in my pcb design i connect SWDIO from programmer to micro and between them i put 330 ohm resistor.same thing for SWCLK as the picture uploaded.
in my board when programming i'm connect my power plug on from adapter
i don't know why this happening.is it because of ESD(Electrostatic Discharge)?Is my design has any problems?
i didn't have this problem for stm32f103.
appreciate your help.
Try releasing the reset button as you start the flashing program, to force the chip into SWD mode. Perhaps you have repurposed PA-13 or PA14 in your program ?
-
Use nRST when possible. If not, you must enable SWIO in the firmware so you can access anytime.
But a bad programming will block SWIO.
If that happens, just short nRST to gnd, click on conect and release reset.
-
i got my answer here
https://www.youtube.com/watch?v=Ib0KMuv6cxA (https://www.youtube.com/watch?v=Ib0KMuv6cxA)
-
The problem is the programmer resets the MCU (there's a magic SWD sequence for this), which after resent immediately starts executing code. The programmer then attempts to halt the processor, but there is a delay in the time it takes the halt to be issued, issued and so the MCU may already have executed your init code that configures SWD out of existence. The result is you can't gain control over it. If you hold RST# this means the programmer is sitting trying to halt by the time you release it and eventually you'll luck out and succeed.
Needless to say, leave the debug pins until you're 100% confident everything else works reliably first, then by all means make minor changes to use them for something trivial that can easily be disabled if you need to debug some problem. But more specifically, I never do this in dev builds; in those if there's a problem and the firmware panics it will sit blinking a LED waiting for me to attach a debugger. The panic message will captured in a buffer, and the traceback will give me the location and stack context. This isn't possible if the pins have been reassigned (either that, or they need to be fiddled with in the panic handler, which I would recommend against also).