STM32 programming with ST-Link problem - 'cannot connect to device'

[Doc Daneeka]

Hi all,

I have some boards with an STM32F030F4, which are programmed and working. I wanted to erase and reprogram one, I have connected the ST-Link V2 programmer, but what ever I do always get the message 'cannot connect to target'.

I have probed the microcontroller pins (SWDIO, SCLK, and reset) and there are definitely perfectly good data signals getting to it. I have configured the the programmer to 'connect under reset' and the device is definitely held in reset (confimed by probing the reset pin and by the fact the application already on there stops running, and restarts when the programmer is disconnected). I have tried every possible serial frequency setting, connecting the boot0 pin to vdd and ground, nothing. I know these devices are good, because they were programmed by a 'copy' st-link programmer and they have working firmware on them. The read protection bit might be set, but I don't care, I just want to erase the device (even choosing 'erase memory' in the st link program just says cannot connect to device). I know the programmer works because I have been using it for other things. I even tried the 'copy' STlink programmer that I know was used to program them (the exact actual device), but still 'cannot connect'.

Any ideas from the STM32 aficionados out there? I feel like I must be doing something blindingly obviously stupid. If it has something to do with the protection bit, how can I erase the flash? As far as I have read I think I am doing everything right (and this is not just one board either, same results with 2 different ones...)

[dgtl]

The FW running inside those may block the SWD port. Put the uc into bootloader using boot0 pin and then try to connect with debugger.

[Rolo]

Try setting the programmer options to "connect under reset". Then press reset on the target controller, keep it pressed while klicking on connect in the programmertool, release reset on controller. Programmer should connect to the controller now.

[digital_dreamer]

What IDE are you using?

[DaJMasta]

It wasn't on a dev board, but most of the time I've ran into issues connecting, it's been that the reset pin is being held low, or a power or ground pin isn't hooked up/powered or grounded correctly.

It could definitely be related to the program running (if you configure a programming pin as a peripheral or something), but holding boot0 high and resetting would probably fix that - since that forces running the program in RAM instead of from flash.


Now that I'm thinking about it, I've also run into problems like this when the ground wasn't fully connected to the programming device.


You've probably at least checked those basics, but maybe it's worth rechecking, at least that's been my experience.

[Jeroen3]

Did you also connect target Vcc to the jtag/swd connector?

The power supply from the application board is connected to the ST-LINK/V2 debugging and programming
board to ensure signal compatibility between both boards.

[Doc Daneeka]

Did you also connect target Vcc to the jtag/swd connector?

The power supply from the application board is connected to the ST-LINK/V2 debugging and programming
board to ensure signal compatibility between both boards.

Sure did, I know everything is fine since my hardware and software and everything works on unprogrammed boards. The issue is boards (same hardware/boards just to be clear) programmed with firmware written/programmed by someone else - I just want to erase them!

It wasn't on a dev board, but most of the time I've ran into issues connecting, it's been that the reset pin is being held low, or a power or ground pin isn't hooked up/powered or grounded correctly.

It could definitely be related to the program running (if you configure a programming pin as a peripheral or something), but holding boot0 high and resetting would probably fix that - since that forces running the program in RAM instead of from flash.


Now that I'm thinking about it, I've also run into problems like this when the ground wasn't fully connected to the programming device.


You've probably at least checked those basics, but maybe it's worth rechecking, at least that's been my experience.

Yep I thought of the boot pins too, I have tried putting the boot pins in every configuration (it is not a dev board). The thing is that the program cannot be running, since the stlink programmer is holding the reset pin low - the device 'should' be held in reset in this state

What IDE are you using?

I am not using any IDE, just trying to program/erase the device with the STM32 ST link utility

[AndyC_772]

Some STM32 devices support multiple levels of read protection:

- level 0 is 'unprotected'
- level 1 is read protected. You can set the level back to 0, but doing so completely erases the chip.
- level 2 is 'this device will never, ever talk to a debugger again'.

At level 2 the JTAG interface is completely and permanently disabled. The chip will continue to run the firmware programmed into it, but if you ever want to change anything, it's scrap and must be physically replaced with a new part.

[Jeroen3]

Level 2 is indeed an irreversible operation. When writing 0xCC to the RDP byte the chip will not allow the RDP to be disabled ever again. Not from jtag and not from user code.

[Doc Daneeka]

Some STM32 devices support multiple levels of read protection:

- level 0 is 'unprotected'
- level 1 is read protected. You can set the level back to 0, but doing so completely erases the chip.
- level 2 is 'this device will never, ever talk to a debugger again'.

At level 2 the JTAG interface is completely and permanently disabled. The chip will continue to run the firmware programmed into it, but if you ever want to change anything, it's scrap and must be physically replaced with a new part.

Level 2 is indeed an irreversible operation. When writing 0xCC to the RDP byte the chip will not allow the RDP to be disabled ever again. Not from jtag and not from user code.

Oh damn: I missed that. That explains it!

That is interesting, what is the intended point of that? Normal write protection 'is enough' to protect your firmware, the only reason I can think of using level 2 is to stop someone buying your product and putting their own firmware? I will have a talk to the person who programmed these boards, as I don't think 'preventing people buying and using their own firmware' should be a major concern for a $5 product... but then again neither is the abillity to reprogram them (except in my case at the moment it is a pain...)

[Jeroen3]

Just replace the chip. Can't be that hard.