Skip to main content
Henrik Sandaker Palm
Associate II
January 15, 2017
Question

STM32F042 refuses programming

  • January 15, 2017
  • 1 reply
  • 1621 views
Posted on January 15, 2017 at 14:56

Hi,

I have a custom board that I used successfully with a ST-LINK V2 and OpenOCD in SW4STM32 for a while. Then I did something, can't remember exactly what, but it was during debugging I think I lost connection somehow and never got it back up. The code that is on the mcu executes fine, CDC VCP drivers enumerates and it works, only it will not program.

So now my target won't communicate over SWD anymore. I've checked and double checked my cables, continuity all the way from the debug dongle to the mcu pins. I've tested two different ST-LINK V2 debuggers, two different cables. Also tried ULINK2 in SWD mode in Keil uVision.

Strange thing is, if I set Connect & Reset Options corect under debug-settings in uVision, it reads the device IDCODE, and I can hear that it resets the device because the USB VCP port re-enumerates. Though uVision will not write anything to flash, though.

If I look for a pull on the reset line using an oscilloscope while using STLINK V2, I see nothing. I see burst of data on SWDIO and clock pulses on SWDCK, but nothing on the reset line. I could swear I've seen a pull on the reset line here before? By the way this is true for both OpenOCD in SW3STM32 and using ST-LINK Utility, tried all different reset-settings.

So is the reset line supposed to pull down before data starts spewing? ULINK2 does this while reading device ID, but not later when trying to write to flash. 

Can I have activated a write protection somehow? And how can I confirm if I've done it?

By the way, right now I don't have the opportunity to try and program a different chip with my three debuggers, nor can I try a fourth debugger on my one chip. Tomorrow I may have time to replace the chip on the one pcb I have.

    This topic has been closed for replies.

    1 reply

    Henrik Sandaker Palm
    Associate II
    January 15, 2017
    Posted on January 15, 2017 at 19:19

    I have now tried my debygger dongles on a different mcu, on a different pcb, and that works. So somehow I've managed to corrupt SWD capabilities on my mcu. Any ideas?

    S.Ma
    Principal
    January 15, 2017
    Posted on January 15, 2017 at 20:00

    Hmm... How about forcing boot pin to start in bootloader mode, then try either to mass erase, or SWD in this mode? Disconnecting debug port while MCU is in debug mode is unusual practice. 

    Tesla DeLorean
    Guru
    January 15, 2017
    Posted on January 15, 2017 at 20:32

    +1 for pulling BOOT0 HIGH, lets make a determination if your code is causing issues.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..