'Connect under reset' no longer working for unknown reasons

[craig239955_stm1_st]

Posted on July 28, 2016 at 14:03

For the last few months I've been working on a project that used an STM32F030 microcontroller. Due to a shortage of GPIO I've had to use the SW debug pins for other functions. Until recently this wasn't a problem, since I just made sure to hook up the reset line from the ST-linkV2 and set it up as 'connect under reset'.

In the last few days I've been unable to reprogram the board though, all of a sudden it just started saying 'no target detected' any time I try to program it from Keil uVision.

I thought at first it may just be the ST-link that was playing up, so I tried a couple of others with no avail. Similar situation with multiple other target boards. Then I thought maybe something I had done accidentally in software, but nothing should really stop it from resetting itself and being able to program..?

The only way I've found I can reprogram them is if I pull the Boot0 line high, then power the uC up, and proceed to program. This is a total pain though since it means retrofitting every board I have with a boot0-high jumper.

Does anyone know what's going on here that might be stopping my programming this system the way I always have in the past?

#stm32 #st-link

[AvaTar]

Posted on July 28, 2016 at 14:41

To ''connect under reset'' is a property /method of a debugger. The JTAG/SWD pins are the debugger's interface to the core - for erasing, flashing and debugging.

> Due to a shortage of GPIO I've had to use the SW debug pins for other functions.

 

This is the cause.

> I've been unable to reprogram the board though, all of a sudden it just started saying 'no target detected' any time I try to program it from Keil uVision.

 

And this is the effect.

> The only way I've found I can reprogram them is if I pull the Boot0 line high, then power the uC up, and proceed to program.

 

As long as you use the JTAG/SWD debug pins for other purposes, this is the only way (barring high-energy ionizing radiation).

[craig239955_stm1_st]

Posted on July 28, 2016 at 14:57

Except for many months before this it has not been an issue, so clearly using Boot0 is not the only way. From  my understanding, connecting under reset (and giving the programmer access to the Reset pin) had allowed the ST-link to pull the device into reset prior to programming, providing it access to the uninitialised SW debug lines. 

I don't understand why it worked consistently with no boot0 manipulation before, but will not now...

[Tesla DeLorean]

Posted on July 28, 2016 at 15:17

Well I suspect the time between the reset and you meddling with the pins comes into play. That BOOT0 works means *none* of your code is running, which suggests it is your code that is the issue here.

Consider what *you* have changed in the way it behaves during this time, or if the firmware in the ST-LINK was changed. Newer firmware might address known issues.

That you don't have an ability to get to BOOT0 easily by your design choices, that's unfortunate, but not exactly unforeseeable.

[craig239955_stm1_st]

Posted on July 28, 2016 at 15:43

What could be causing this in my code though?

I thought the whole point of 'connect under reset' was to allow the device to be programmed even if you used the SW debug pins. That way the programmer, through access to the reset pin, can reset the system and initiate programming prior to reassigning the other pins. Am I mistaken in this thinking? I am very confused because I'd been using those pins before with absolutely no issues or requirement to use the boot0 pin.