The issue here is whenever I upload firmware to the Stm32 bluepill board I can’t debug or reupload until I disconnect the board or press the reset button on the Bluepill Blackmagic probe clone board. I checked the SWIO line and It is always latched high after uploading but when resetting the board the SWIO line is Low and allows interaction.
I not an expert but I think that the Blackmagic probe clone firmware missed the hardware resetting part’s code, I am not sure though!
How to solve this by allowing for software-controlled resetting of the dev board instead of the necessity to press the reset button after every upload?
I’ve observed the same. Most likely, the MCU is not properly reset.
I don’t understand yet if it is a bug or limitation that has to be addressed by the Black Magic Probe team, or if it provides the necessary commands and could be fixed with changes on the PlatformIO side.
I’ve done some testing and found two projects, one exhibiting the problem and one working without a problem. It took me about half an hour to find the relevant difference.
In the working project, I specified the upload port as /dev/cu.usbmodemBA9876571 and in the problematic project as /dev/tty.usbmodemBA9876571. Do you spot the difference? It’s cu… vs tty….
I don’t know if you are working on macOS as well (and it might also apply to Linux). The chances are that you have specified an invalid serial port.
BTW: Each serial port has two devices. /dev/tty... devices are so called call-in devices. They wait until the modem signals via the DCD line that an incoming call has been answered. /dev/cu... devices on the other hand are call-up devices for outgoing calls. They don’t wait.
Thank you so much. I changed the port from a /dev/tty.usbmodemxxxxxx to /dev/cu.usbmodemxxxxxx and It is working fine now! Now I can upload and reupload the firmware again without the need to unplug or reset the microcontroller!
I still am not sure what the exact reason or limitation might be. It will be better if someone could explain in detail to us.
The reason is as explained in the last paragraph of my answer: /dev/tty... is a call-in device and waits for an incoming called when opened. This dates way back in Unix/Linux history to times when modem where used to connect computers.
What I can’t explain is why it works once. I would expect that it doesn’t work at all with /dev/tty....