the STLink is the cheapest, with clones costing like 5€. All the other listed ones are prohibitively expensive for hobbyists. The STLink has general SWD connections (SWDIO+SWDCLK), so it’s not limited to STM32 processors, but can do other ARMs too, like the MCU on the Due. I use my ST-Link for debugging various chips a lot and it hasn’t failed me yet.
Note, when you have such a debugger, you must make the SWDIO connections between the Due and your debugger per pinout. The “DEBUG” header has all needed signals, and TCK (testclock) is “SWDCLK”, “TMS” is SWDIO and RESET is also nRST. Those will also be labeled on the STLink. Additionally, you need common GND (aka GND from STLink to GND of Due).
To tell PlatformIO that you are now using an ST-Link, you have to configure your platformio.inias documented with
Of course. I can show you setup. I did also connect it to USB. But here are some pictures. Before I show the pictures, I will mention that I tried this same setup with both a USB and AC socket as power and they both resulted in the same error.
Also, does it matter if the power is supplied through Programming port or Native Port? I also used 5v supply and 6v supply when connecting to the AC socket.
I also think I should mention that I was able to get my hands on one of these from a friend of mine at school
However, when connecting it and running a debug, I still got 2 errors, except the “Unable to set adapter speed” error was switched out with one saying that the target voltage was too low.
This post confirms it should be working on ST-Link v2. There’s also this config file but it’s basically the same as the command above already.
The “unable to set adapter speed” may be a smoking gun here, that shouldn’t fail with the default speed of 500kHz, it should just adjust to use 480kHz instead.
Can you please set
debug_speed = 480
in the platformio.ini and try debugging again? Is the error message now gone in the Debug Console?
Just to make sure, after clicking on the run and debug tab, I just need to run the debug on the “PIO Debug” configuration, right? Because besides that I am not doing anything else in the debug section besides switching from Debug Console to Terminal, and vice versa.
This was the result of changing the debug_speed and running the PIO Debug
I will follow your instruction on updating immediately after this.
Okay so we went from having no connection to the chip at all to having a connection but failing to flash. Some progress. Sad this not working out of the box.
Can you rerun the command from above? What does it say now?
If the program has connected successfully, use Ctrl+C to stop it again.
Yes, it very succesfully discovered and connected to the Cortex-M3 processor. Very good.
This is now a PlatformIO fault that it wants to flash to address 0x0. Lookg at the datasheet’s memory mapping, it looks to me like 0x0 is where the bootloader is (if this is non-modifyble we can’t write stuff there) and 0x80000 is where the actual internal flash is where the program should live.
No, that’s actually good and says that the debugging probe (STLinkv2) was able to halt execution on the chip so that it can read out the memory (for variables etc.) in peace. You’d have to worry about “failed to halt target” messages if there were any.
The output look very good. Can you stop debugging (stop button) and add
Then if you start debugging now and if everything works it should now halt in the setup() function of your firmware code, indicated by a highlighted red or yellow line in the source code (“current execution position”). From there you can try to use the “step over” (arrow) button to step over the lines of code in your firmware.