How many pins are required to program an STM32 chip?

[AQUAMAN]

Do I just need 3 pins? SWDIO, SWCLK and GND?

[langwadt]

Do I just need 3 pins? SWDIO, SWCLK and GND?

yes, but it is convenient to have reset as well

[Yansi]

Reset pin required too, if you use the SWDIO/SWCK pins as GPIO, or if wakeup from low power mode needed. But it is not mandatory.

[Kjelt]

And your target device should have Vcc, otherwise you should connect that too.

[SiliconWizard]

Seconding what has been said above: answer is: it depends on what you want to do, the context, etc.

As said above, a nRST pin from the SWD probe is a good addition. Without it, you may be unable to access your MCU through SWD if it's in a low-power state, so if you plan on using low-power states, it could be extremely annoying if you don't have this pin. Actually been there before.

As to Vcc/Vdd, it all depends on your target voltage and on the SWD probe you're going to use. If the latter has an embedded level shifter, it's a good idea (or even sometimes mandatory, depending on the probe) to connect the target's Vdd to the corresponding pin of the probe.

So you said too little. What's your target Vdd, what's your MCU and what's your SWD probe? Is this for a particular project or do you want a more generic solution?

[AQUAMAN]

Seconding what has been said above: answer is: it depends on what you want to do, the context, etc.

As said above, a nRST pin from the SWD probe is a good addition. Without it, you may be unable to access your MCU through SWD if it's in a low-power state, so if you plan on using low-power states, it could be extremely annoying if you don't have this pin. Actually been there before.

As to Vcc/Vdd, it all depends on your target voltage and on the SWD probe you're going to use. If the latter has an embedded level shifter, it's a good idea (or even sometimes mandatory, depending on the probe) to connect the target's Vdd to the corresponding pin of the probe.

So you said too little. What's your target Vdd, what's your MCU and what's your SWD probe? Is this for a particular project or do you want a more generic solution?

I'm not using any low power mode. The chip will run on 3.3V
I've got a ST32G431 32 pins
It's the first time I'm trying to program a chip without a breakout Arduino type board. I'm currently designing the PCB

[peter-h]

I am using the tiny 10-way connector in post #1 here
https://www.eevblog.com/forum/microcontrollers/10-pin-debug-connector-and-stlink-v3-isol-not-reliable/

You need these for the basic SWD debugging.

Pin 1 (target voltage) probably isn't if the debugger is not target powered, but some debuggers (e.g. STLINK) use it to measure and report the target VCC. Not sure that actually works on their ISOL models. Any isolated debugger is likely to need that pin because it draws power from it to power its isolated (target-side) circuitry; that can be avoided with a DC-DC converter in the debugger but I don't know how many have that.

[Siwastaja]

GND, TX, RX also an option for factory UART bootloader, answering the question regarding programming (but not debugging) an STM32. BOOT0 needs a jumper or pushbutton to enter the bootloader during power-up, but not necessarily a connector pin. Reference manual explains which UART is available in the bootloader.

[Jeroen3]

Typically, to program ARM Cortex devices you need only 4 wires.

Ground
SWDCLK - arm swd clock
SWDIO - arm swd data
Vcc-sense -  level shifter target voltage sensing

A more fully featured debug port may also include:

Reset - to reprogram parts with readout protection (since swd core reset is then often unavailable)
SWO - trace output

On ARM powering the target via the debugger is rare. Usually the debugger takes a voltage reference from the target to set the buffers, 1.8V, 3.0V, 3.3V. Like ST-Link, ULINK or Segger*. Since ARM can run at various voltages for power reasons.

Often, I place a do not populate resistor in series with reset near where it branches of to the debug header. So production boards won't have reset bu default. While prototype/test/repair board can e reprogrammed.
Availability of SWO depends on the luxury of the pin being available.

ST does not require specifics to program. But boot configuration and pins need to be right to run the program.

_{*Segger offers optional 5V target power output.}

[dgtl]

I'll mention that in addition to the JTAG/SWD, the STM32 has internal bootloader. If you're interested only getting the binary into the flash of the uc and not debugging features, perhaps it's enough just to hook up one of the debug interfaces and the BOOT0 pin. Pull BOOT0 to system boot mode (BOOT1 can be always set to one value) on powerup and then upload the binary. Usually one of the bootloader-supported interfaces are routed out anyway to an external connector (ie uart or usb), so you'll need only the BOOT0 pin extra. Check for AN2606 for details.

[Siwastaja]

I usually develop using the internal UART bootloader only until I have finished my own in-application flasher or bootloader, at that point I start flashing using that, in many projects I don't bring SWD out at all.

Rolling your own has the benefit of being able to use any interface, obviously usually the one you have already connected for whatever reason.

For example, if you develop an application which normally communicates to a host PC through UART, you can use the same UART to flash with ST bootloader, all you need is a pushbutton / jumper on BOOT0. Then, you can write your own flasher to make the reflash process faster/better (and not require BOOT0 pin) still using the same UART, while retaining the ST's bootloader as a backup procedure.

Debug features rarely needed, in some rare cases they save time, in such cases I lose a little bit of time (for example: store ten interesting peripheral registers in temporary variables, print out later, takes 2 minutes instead of 10 seconds in a debugger register view) but save it elsewhere.

[Yansi]

Debug features rarely needed, in some rare cases they save time, in such cases I lose a little bit of time (for example: store ten interesting peripheral registers in temporary variables, print out later, takes 2 minutes instead of 10 seconds in a debugger register view) but save it elsewhere.

Awww... the classic siwastaja mantra. 

This is how you program an arduino, not a complex application for a 32bit MCU. And you are again even speaking against yourself: You say debug features rarely save time and then proceed wasting time to program lines of println shit in the code. That a) Does not save machine time, as it is useless code for the application b) spend time writing your own debug, instead using the debug interface and proper tools to display values of variables.

Also note, that the debug interfaces are not only for displaying variables, you can do much more with then then your UART Printing "time saver".

[Siwastaja]

As always, I have provided arguments and I have a good track record of succeeding with my methodology.

As always, your main argument is "you just do it this way, period", and you are unable to show me being wrong with actual arguments replying to my claims.

I respect your opinion and workflow and not saying it doesn't work, it's also a good default because it's the usual one, so lot of help and tutorials are available. I also do sometimes use gdb, add breakpoints and singlestep and there's nothing wrong with it.

The fact, not an opinion, is that my workflow works fine, but it's also possible it doesn't work for everyone. I want to offer an alternative viewpoint that is rarely seen publicly; this is because your viewpoint is easily available everywhere already.

Fundamentally all of this is a question between building your own tools versus using existing one-size-fits-all general purpose tools. I just prefer the former. In the end, the importance of understanding the tools and how to use them is what's important. And no tool is perfect of everything, regardless of workflow you have some inefficient moments. The total productivity is what counts.

Reducing my viewpoint into "arduino printf" is a typical strawman argument; in reality you can do a lot more. I could build a similar strawman and accuse you of singlestepping through your program logic inefficiently, but I'm sure you can use debuggers better than that.

[radiolistener]

Do I just need 3 pins? SWDIO, SWCLK and GND?

yes, but you're needs also 4'th pin - Vcc (3.2V power supply)

[mac.6]

Don't bother, there is the standard 10 pins connector for arm cortex, do not reinvent the wheel! both connector and cable are available off the shelf.

[mikerj]

Debug features rarely needed, in some rare cases they save time, in such cases I lose a little bit of time (for example: store ten interesting peripheral registers in temporary variables, print out later, takes 2 minutes instead of 10 seconds in a debugger register view) but save it elsewhere.

How do you "print" these values out without a debug interface?  Means you need a UART etc which may not be available, or some crappy bit bashed interface?

I can't say I share your opinions on this, a good debug interface saves a huge amount of time, and the Segger RTT interface has been a life save on some projects since the IO is so fast.

[Siwastaja]

How do you "print" these values out without a debug interface?  Means you need a UART etc which may not be available, or some crappy bit bashed interface?

Thanks for asking,

Depends on the project. Except for the simplest LED blinkers, usually most projects have either some communication link for the application, or at least some diagnostic port, typically UART, SPI, CAN...

It's instrumentation, the point is, except for trivially simple projects, you need instrumentation (or call it telemetry) of the application in any case, you can't replace it with the debug interface. You log what is happening, for robust development you think about this beforehand.

This is how you debug a vehicle or ECU, you connect the manufacturer's tool to the diagnostics port, you don't connect a debugger in the CPUs debug pins and single step the code.

For an almost IO-less project, they tend to be so simple you don't need to spend hours debugging a problem anyway.

Naturally there are instances where this instrumentation/diagnostics link itself needs debugging, or the CPU hardfaults instantly before reaching the initialization of CAN (for example), for this a debugger may be needed but in my experience I can nowadays usually guess the problem and in any case this happens only during the first few hours of the project. I have used a debugger once during last 5 years I think.

Working with mobile robots (physically somewhere I may not be able to go to access them) really emphasized the point that I just can't connect a probe and hope to catch a problem on the lab table, I need to have instrumentation in the application to store state and report it to catch rarely occurring problems "on the field". I simply don't understand who needs going through the code line-by-line, that's obvious from looking at the code. Instead you need to understand the graph of higher level events, what lead to what, and this is something quite easily done in code, and when it's in code, it stays in your program and you can look at the log after the issue arose on the field instead of connecting the probe trying to reproduce. To give a practical example, this can be as simple as doing this in each non-trivial, interesting function:

Code: [Select]

call_graph[idx++] = 42; // function ID. wrap this as an atomic block.

Then do error checks / sanity checks everywhere and in the error handler, dump everything you have collected into all available interfaces so that if one is down, others can be used.

Another thing I like doing, is adding

Code: [Select]

trace[idx++] = value;

in feedback loop / etc. handlers which handle ADC data for example. Then I have a simple gnuplot script which takes the dump through whatever application bus and plots it like a scope trace; I have attached an example image of such automated output to give you an idea. Yes, you can do the same with some more advanced debug tools saving a few minutes of work, and utilizing the ARM trace macrocell it will have more bandwidth than through UART for example. So this becomes like a penis length competition where you win by buying a 1000HP Ferrari while I get the job done with Toyota Corolla.

I understand the argument of just connecting the probe, examining memory and single-stepping through code being easy, fast and appealing, especially to beginners, but I just think I don't need it, and I'm probably not alone. But anyone is free to go on calling this wrong or crappy, it tells more about them than the methodology itself.

So I'm not against debuggers but I just think people who talk about them like they are silver bullets that answer to all debugging (using the word in the general sense of finding and correcting bugs) needs simply don't know what they are talking about, and many such people being so arrogant*, I like to reply a tad arrogantly as well, but I hope I have provided some actual points you can think about.

*) Making it appear that they have some 5-10 years of experience, are past the beginner phase, remember how much they sucked doing printf on arduino, and are so glad they found debuggers.

[SiliconWizard]

Debug features rarely needed, in some rare cases they save time, in such cases I lose a little bit of time (for example: store ten interesting peripheral registers in temporary variables, print out later, takes 2 minutes instead of 10 seconds in a debugger register view) but save it elsewhere.

How do you "print" these values out without a debug interface?  Means you need a UART etc which may not be available, or some crappy bit bashed interface?

Nope. On STM32 MCUs, you can absolutely use the SWO output without any debugger or even any SWD probe. It can be configured in software and be used as a simple "high-speed" UART (several MHz are no problem depending on the core clock). The only thing you'll need is some UART-USB adapter. I have a handful of them (most of them isolated/FT230X based or similar, which gives me isolation + level shifting). Very handy.

Getting a printf-like interface with SWO is only a few lines of code really.

[dgtl]

How do you "print" these values out without a debug interface?  Means you need a UART etc which may not be available, or some crappy bit bashed interface?

There is an ARM-standard api called semihosting, that will work over the SWDIO during debugging (doesn't require SWO). Basically, it can be used to redirect some streams (stdout, file i/o) to host computer. If you're using openocd+gdb, you have full support out of the box on the host side. The simple way is to enable libc support for semihosting (rdimon.specs), then printf and other standard C stuff just works. But this will add quite a lot of code space, so I typically roll out my own implementation.
There are some downsides, though:
* as semihosting uses breakpoints for data transfer, the mcu core is stopped during printing.
* character-wise output is slow as hell... luckily, there is line-wise output, that is usable.
* debug adapter speed matters. For stlink, it is important to use "reset init", not just "reset halt". Otherwise, the SWD speed is not raised up.
* you need some kind of debug interface detection to avoid stalling the core when no debug adapter is present. For example, read some registers that the debug session init will write (ie stop watchdog when debugging bit)