Avoiding a double reset

Development Platforms
1

This is a minor issue, just something I’d like to streamline a bit further. First some context:

I’m uploading on STM32/CMSIS to RAM (with a modified .ld file) using the command line. The default stlink upload protocol uses OpenOCD for this, which fails because 0x20001000 is not in flash (doh), so I switched to using texane/stlink:

upload_protocol = custom
upload_command = st-flash --reset write $SOURCE 0x20001000

Note the --reset, which is needed to launch the new code properly after uploading.

The issue is that there are now two resets. One before the upload, and one done by stlink. The result is that the old code is restarted (long enough to send some output to serial), and then the new one.

I don’t know where the first reset comes from. I’ve found the upload_resetmethod setting, but can’t find its use anywhere in the PIO scripts or tools - it looks like that is intended for ESP8266/ESP32 use.

Is there some way to disable that first reset?

2

Have you confirmed that when you run st-flash --reset write $SOURCE 0x20001000 there is only one reset?

PlatformIO should in this case only execute the commands you give it. You can execute the “Advanced → Verbose Upload” project task to verify.

3

Aha, good suggestion, hadn’t thought of that!

Hm, the problem is no longer present.
I can no longer reproduce this behaviour, no idea why.
Oh well, my bad - thanks for your helpful suggestion.

UPDATE: It may have been related to a different issue. I used to put the app in a permanent WFI loop when done, and in some cases this happened with no interrupt source active at all (not even systick). It turns out that you can’t upload to the µC in this case. Maybe st-flash detects this, resets to get the upload going, and then resets again at the end due to the --reset arg. I haven’t researched further, but it’s the only explanation I can think of. Either way, the problem would indeed not be PIO’s fault.