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.