Connector for programming
Closed this issue · 7 comments
In previous designs I usually used normal 2.54 mm pin-pitch headers for programming. However, it is often quite tricky to connect the pins correctly with jumper wires during testing and even more for re-flashing in the field during prototype evaluation.
As a solution, there is the Tag Connect, which is widely used in the industry. However, it's around 40€ for a simple cable, which is available from a single vendor only.
Würth offers a 2.54mm pitch press-fit connector, which can be used with standard ribbon cables. The connector can be mounted permanently or it can be used temporarily for flashing and debugging only (using slightly larger hole diameters). There is also a white-paper about use of this connector for debugging.
The connector is available e.g. via Digikey. I didn't look for compatible second sources, yet. However, also two normal 2.54 mm pin header rows could be soldered to the footprint to interface with jumper wires as a quick workaround if someone doesn't have the connector.
I suggest the following pinout:
A reset pin is not needed for SWD, as the MCU can be reset via the SWD interface itself. This leaves space for a serial interface for debugging in a 6-pin connector.
Let me know if there is a preference for a changed pinout. The boards are not ordered, yet.
CC @EarthLord
Although we use Tag Connect, I agree that its quite costly for a simple cable. Würth connector is quite interesting, only somewhat bigger. Also I recently came across this idea for a programming connector, quite ingenious. Thoughts?
https://avdweb.nl/arduino/misc/mini-isp-connector
Once I had an experience where after entering deep sleep with STM32 I couldn't program it again without the reset pin. So maybe have reset instead of 3.3V? In any case the board can get power supply from elsewhere - even UEXT connector in the rare scenario where the board is not powered from a battery and it needs to be programmed/debugged.
If you can confirm reset isn't needed to program in any sleep state, then the current pinout is fine.
Ok, thanks for the insight regarding your issues with the reset from deep-sleep. So we should at least break out the reset pin to a test point so that it can be reached during debugging, just in case.
Unfortunately, the voltage pin is needed. It is not for powering the board, but for the programmer to detect the system voltage. As far as I understand, it is mandatory e.g. for Segger J-Link and also the STM32 nucleo boards have it.
The zigzag connection is neat, indeed. I knew the zigzag footprints as a soldering aid from Sparkfun Eagle libraries, but for programming it's also a nice idea.
I also like this one: https://hackaday.com/2016/02/08/local-hacker-discovers-card-edge-connectors/
But inside an enclosure the board edge may be hard to reach, so accessing it from the top is a must, IMHO.
Here is another edge-connected solution with an open standard: https://debug-edge.io/
It confirms that SWD cannot be used without the voltage pin (see the 4-pin version).
Yes, the voltage sensing is needed for a programmer/debugger, although I usually connect this sensing pin to the 3.3V from the programmer itself, especially with nRF-DK boards to trick the programmer to think the power is fine.
As you say if accessing from top is needed, we can do the zig-zag pattern?
Yeah, I think I'll actually switch to normal pin header with zig-zag. I like the idea.
I'd probably keep 2.54 mm pin-pitch headers, though. The link you posted above seems to have 1.27 mm pitch. What do you think?
Maybe I'll just leave out the serial, so that one has to take the serial from the UEXT connector for debugging. It would leave us with a 5-pin single-row header, which is small enough.
Regarding the pin header pitch, not sure if 2.54 mm one is be harder to insert in zig-zag because it is thicker and not as easy to bend. Its a small risk to figure out the zig-zag offset for 2.54 mm pitch. If there is space, can be experimented in first version.
Also, leaving the serial on UEXT for GSM would be good, so a UART dedicated for debugging/manufacturing would be useful.