Serial3 Not Working

From the support debug protocols,

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.ini as documented with

; upload + debug via stlink
upload_protocol = stlink
debug_tool = stlink

grafik
grafik

1 Like

Just ordered one, I like the idea of collecting things for my MCU/component collection. Really looking forward to it tomorrow.

What would be the next step after this?

If all cabling is right, you can try to go do the debugging sidebar or menu and press the Play button / “Start Debugging”.

https://docs.platformio.org/en/latest/tutorials/ststm32/stm32cube_debugging_unit_testing.html#debugging-the-firmware

https://docs.platformio.org/en/latest/plus/debugging.html#tutorials

Watch the output in the “Debug Console” tab for errors.

If it can connect, you should see that one line is highlighted and you should have debugging controls for play/pause, step over, step into, et cetera.

1 Like

Okay so it must be that simple then. This is the error I am receiving in the debug console, regardless of the success message in the terminal.
image
Am I missing on adding something to my configurations/launch.json file?

P.S.: Should this be moved to a new thread?

Open a new commandline (Windows + R → cmd.exe). Then change-directory (cd) into your PlatformIO’s openocd installation

cd .platformio\packages\tool-openocd

Then just execute the OpenOCD command that PlatformIO would to connect to the chip

bin\openocd -s scripts -f interface/stlink.cfg  -c "set CHIPNAME at91sam3X8E; set CPUTAPID 0x2ba01477" -f target/at91sam3ax_8x.cfg

What does just that output?

This is what I got as an output:

Can you show a picture of your setup? A STLink is definitely detected, but it can’t connect to the Due.

SWDIO, SWCLK, RESET and GND need to be connected between the Due and the STLink.
Additionally, the Due needs to be powered (e.g. via USB).

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.

Your wiring looks perfect. You even recogninized that the pinout diagram above didn’t list the pins in-order and plugged them in correctly.

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?

In addition to that, the firmware version on your STLink is not yet up-to-date (V2J29S7).

The newest one is V2J40S7

You can get the update tool after an account registration from

https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link007.html

Or I also uploaded it at Deleted

The update worked with my device just fine.

Setting debug_speed:
image

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.
image

This was the result of changing the debug_speed and running the PIO Debug
image

I will follow your instruction on updating immediately after this.

Upgrade was successful.

After updating, I received a new message when running the PIO Debug.

image

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.

Seems to have had a bit of progress.
Did I do the Ctrl+C correctly? I am still new to command prompt as well.

After this step I ran a PIO Debug again, and I received the same exact error about “no flash bank”.

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.

Let me just double-check these memory addresses and how PlatformIO links the application and see how we can solve this very likely bug.

Now I also get why videos like PlatformIO Tutorial: programming Arduino DUE with Atmel-ICE / ST-Link - YouTube use a custom script that use the 0x80000 address to fix PlatformIO’s bug.

1 Like

Actually, the platform might have a configuration option there that might correct it.

Can you add

board_upload.offset_address = 0x80000

to the platformio.ini and retry debugging?

Of Course.
image


There seems to have been success! Do I need to worry about any of the ‘target halted’ messages.

I guess my real question is, do you see any errors? I assume that I will get used to this the more I work with the debugger.

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

debug_init_break = break setup

(docs) to the platformio.ini.

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.

1 Like