Author Topic: after few programming debugger can't recognize microcontroller(stm32f101vbt6)  (Read 677 times)

0 Members and 1 Guest are viewing this topic.

Offline tariqTopic starter

  • Contributor
  • Posts: 24
  • Country: ir
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.


 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
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 ?
 

Online DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5835
  • Country: es
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.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline tariqTopic starter

  • Contributor
  • Posts: 24
  • Country: ir
i got my answer here
 

Offline bson

  • Supporter
  • ****
  • Posts: 2265
  • Country: us
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).

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf