STM32F042 refuses programming

[Henrik Sandaker Palm]

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.

[Henrik Sandaker Palm]

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]

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]

Posted on January 15, 2017 at 20:32

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

[Henrik Sandaker Palm]

Posted on January 15, 2017 at 21:03

KIC8462852 EPIC204278916 wrote:

Disconnecting debug port while MCU is in debug mode is unusual practice. 

You only live once

KIC8462852 EPIC204278916 wrote:

Hmm... How about forcing boot pin to start in bootloader mode, then try either to mass erase, or SWD in this mode? 

Clive One wrote:

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

When I pull BOOT0 high while powering the mcu it executes code as usual. But it has always done that. I haven't come as far as to look at bootloaders, but what should I expect when powering it with BOOT0 high?

I just made a discovery. By forcing reset line low during SWD ''negotiating'' I am able to connect to and program the target via STLINK Utility. I can also do this when going into debug mode in SW4STM32, but the connection fails when I press Run.

Also forgot to mention that the other target I managed to program normally did not have the reset line connected at all. STLINK utility probably fell back on programming without reset?  

So here I managed to read out my option bytes. I am investigating it now to the best of my knowledge, but you may chime in if you see anything:

[Henrik Sandaker Palm]

Posted on January 15, 2017 at 21:10

This should maybe go into a new thread, but why is nBOOT_SEL greyed out in the image above? Reference manual says this option is for choosing whether pin or software puts you in bootloader mode:

[Tesla DeLorean]

Posted on January 15, 2017 at 22:07

>>When I pull BOOT0 high while powering the mcu it executes code as usual. But it has always done that. I haven't come as far as to look at bootloaders, but what should I expect when powering it with BOOT0 high?

The primary goal is the have the processor run some safe code from which you can erase/program the device rather than running broken code you may have loaded. Think low power mode, interfering with the GPIO pins, etc.

[Henrik Sandaker Palm]

Posted on January 16, 2017 at 09:20

I expected to run the bootloader from within 'system memory'. In previous STM32s I've worked with where I was not the software architect I simply pulled the BOOT0 pin high when powering the device, and it entered bootloader mode and did not execute code from main flash memory. This is not what I'm seeing here.

Okay. I'm thinking low power mode, interfering with GPIO pins, etc., but I don't understand where I am going with it? In what context did you say that? Can I interfere with the BOOT0 pins by configuring it as GPIO? I think not, but since you're mentioning it. Do you need to see my schematic?