Which is Correct; 4-wire SWD without Reset OR 5-Wire SWD with Reset?

[eewiz]

I see numerous examples of 4-wire SWD without a reset pin connection.

I come from the PIC world where there is always Data, Clock and Reset for a Pgm/Dbg interface.

I bought a Chinese STLink-V2 programmer/debugger and it has a reset pin as well as data, clock, GND and VSS.

Although, the Chinese STLink-V2 comes with a 4-conductor cable for attachment to my target.

Do I need to connect the Reset pin?

Also, anyone know of an Ap-Note that covers the electrical nature of the SWD interface.

Thank You

[Piranha]

> In my application PA13 and PA14 are dedicated to SWD only.

That is not enough. Under reset the PA13, PA14 pins are configured as SWD pins, but, when the CPU starts running your firmware, the your code can reconfigure those pins into a GPIO or some other configuration, disabling the SWD (and erase/program) capability. Read AN4325, section "4.3.2 SWD pin assignment". Keeping NRST low, stops the CPU from executing code and therefore from disabling the SWD. All STM32 MCUs can do this. The STM32L011D3 datasheet just notes that for a specific package under certain circumstances the "connect under reset" is absolutely necessary.

Add the NRST signal to connector even if your current debugger doesn't have that signal. You will thank me later, when you'll buy a decent debugger like a real ST-LINK or J-Link EDU Mini, both of which are pretty affordable. And, even if not, in those emergency situations at least you will have a pin, which could be easily connected to GND with a wire, button or screwdriver.

[eewiz]

Thank You Piranha

I used MX to set PA13 and PA14 to SWD.

My code does not alter this situation.

PA13, PA14 and nRST are connected to the SWD header only.

No reset button. Power cycle only.

I always did plan to implement a 5-pin SWD connector on my target.

The F030 does not do SWO. I have no need for SWD pin six.

I started this thread because I was confused by so many google examples of SWD shown without nRST.

I just ordered a v3MINIE and an F072B-Discovery so I should be able to get something started.

They cost about the same as 5 of the Chinese debuggers.

So now I will have seven debuggers. I will have a number of targets communicating with each other so I will be using more than one debugger simultaneously.

I ordered the Chinese debuggers from Amazon because I simply could not determine what it was that I needed from the info available on the ST website. At that time I was totally confused.

3-pin, 4-pin, 5-pin, 6-pin, 10-pin, 14-pin, 20-pin, MINI, MINIE, MODS, SET, v2, v3 made my head hurt.

All I knew for sure is that the F030 was SWD not JTAG.

Now, a week later, I understand, thanks to all who have posted.

Thank You

[Piranha]

> My code does not alter this situation.

The forum is full of posts where people do it accidentally... ;)

> They cost about the same as 5 of the Chinese debuggers.

But they are reliable, can update the debugger firmware and have NRST and SWO pins.

[Harvey White]

I found the update capability to be less than accurately described. I have a small doorstop suitable for a cat door.

The 22 ohm resistors are in series with the connection from the processor to a number of things:

1) the programming interface

2) the QSPI memory (AP6404L connected to the QSPI interface on an L5 processor. Not all processors support this)

3) the FMC interface to an S1D13517 (Epson) graphics controller chip.

4) a clock line or so (for the S1D13517).

Note that these are not pullups or pulldowns, but are included to damp reflections on the lines, and form a small low pass filter for possible ringing. If you check the designs on say, some of the disco boards, you will see that they do much the same thing. It may reduce the need to length match some of the data lines on the faster signals. It does work (didn't try without it) on the QSPI memory lines. The price of 22 or 33 ohm resistors (0402) is so small that a thousand of them is almost a throwaway.

The boards are 4 layer boards with a ground plane and 3 other planes (slightly complex board), and the signals seem reasonably well behaved.

You can argue whether or not the resistors are needed on the programming pins, but I rather suspect that they are needed on some of the other lines (such as FMC signals).

[eewiz]

Harvey

I just successfully upgraded my Chinese debugger.

Here's how I did it.

Plug in the debugger.

Start CubeIDE.

Go to the Debug View.

Select Run/Debug Configurations.

Double-Click STM32 C/C++ Application.

Select Debugger Tab.

Select AutoStart GDB Local Server.

Select Debug Probe = ST-LINK (ST-LINK GDB Server).

Select SWD.

Select ST-LINK S/N and click Scan button.

If what looks like hex serial number fails to populate the box then STOP, your debugger is kaput.

Mine populates with something like "121F14002E15374...."

Click the DEBUG button which leads the upgrade prompt.

Click to upgrade which starts the STLinkUpgrade dialog. Mine is v3.4.0.

Mine had some bogus ST-Link ID like "3030303030303030301".

If you click Refresh Device List, nothing happens.

If you click Open in Update Mode, you get a failure message something like "The Debugger is not in DFU Mode".

Simply unplug the debugger from it's USB port.

Take a deep breath and plug it back in to the same port.

Go back to STLinkUpgrade.

Click Refresh Device List.

It says that debugger "3030303030303030301" appears to be defective but I found debugger "121F14002E15374...." would you like to use it.

Say yes.

Click Open in Update Mode and the Upgrade button will light up.

Click the Upgrade button.

Here's the result:

You may wish to resurrect your door stop and see if this works.

That's all for now

[Harvey White]

Thanks. I'll try that after a while. For now, I'm busy rewriting and restructuring a large piece of software to use Azure (if I can), rather than FreeRTOS. I figured it's better to try the rewrite than use the FreeRTOS translation layer. Makes me get familiar with Azure, anyway.

Of course, now I have to find the doorstop.........