The sorts of things I do don’t really have space for a 0.1″ pitch JTAG header, and the ‘official’ ARM 0.05″ 10-pin seems a bit awkward to make cables. The 6 pin/5 signal Serial-Wire Debug-Port (SW-DP/SWD) is much more attractive.
Also, I use off-the-shelf development boards like ST-Discoveries and ST-Nucleos, which only have the 6 pin/5 signal SWD headers anyway. So a 10-pin JTAG seems pointless. Wiring up a 10-pin JTAG for a Maple Mini is less attractive than SWD too.
Q1. Can anyone tell me if a SWD only Black Magic probe is supported in the firmware and drivers, or must it be a 10 pin JTAG?
I am tempted to reflash the on-board ST-Link with BMP (and may do that), but the project I have in mind appears to be tidier with my own ourduino-mini and a separate compact debugger, something like the Black Magic probe mini. However, the mini isn’t very DIY friendly, it uses quite small parts.
I looked at the Black Magic Probe mini schematic.
If the 10-pin JTAG interface were reduced to SWD, saving a couple of I/O pins, I think an STM32F in a 20pin TSSOP20 would have enough I/O to implement it. The 20pin TSSOP should be a bit easier to DIY than an LQFP. I think about unskilled beginners making stuff, so this is important.
I had been thinking of using an STM32F042, because it has ‘crystal-less’ USB, and is available in a TSSOP20.
However the STM32F070 seems to be a similarly low-cost including an 8MHz crystal, and is available in a TSSOP20.
There is a ready-made ST-Nucleo for both of them, so development shouldn’t be too hard.
Q2. Has anyone any views on STM32F042 vs STM32F070 as a basis for a Black Magic Probe?
So, the F103C8T6 is the minimum requirement.
Anyway I cant see a reason not to use this MCU, the price is minimal and the soldering is not so difficult, and most of all, it is possible to use the blue/red pill directly, or on a small PCB…. nothing is more cost effective.
As others have pointed out, fitting the full BMP functionality (with the GDB protocol and target MCU flash algorithms) may not be possible in only 32KiB of flash. However, if you’re willing to have the host computer manage more of the debugging logic (via OpenOCD or a commercial debugger), you can easily fit a CMSIS-DAP debug implementation in < 16KiB.
I just double checked the size of my current firmware, and it’s sitting at about 14KiB right now.
https://github.com/devanlai/dap42
With the TSSOP-20 package, you can build a debugger with SWD, 3-5 GPIO, and one hardware UART xor SWO input.
As others have pointed out, fitting the full BMP functionality (with the GDB protocol and target MCU flash algorithms) may not be possible in only 32KiB of flash. However, if you’re willing to have the host computer manage more of the debugging logic (via OpenOCD or a commercial debugger), you can easily fit a CMSIS-DAP debug implementation in < 16KiB.
I just double checked the size of my current firmware, and it’s sitting at about 14KiB right now.
https://github.com/devanlai/dap42
With the TSSOP-20 package, you can build a debugger with SWD, 3-5 GPIO, and one hardware UART xor SWO input.
With all the features for both JTAG and SWD it is still fairly small but not small enough for 32KB:
$ arm-none-eabi-size blackmagic
text data bss dec hex filename
53452 168 2132 55752 d9c8 blackmagic
Thank you very much for all of that helpful information. Lovely news. Best of luck.
Are you thinking of releasing as Open Source, or is it too early to say?
But one of the ST guys I spoke to at Maker Faire said he used this
https://github.com/x893/CMSIS-DAP
see also
But one of the ST guys I spoke to at Maker Faire said he used this
https://github.com/x893/CMSIS-DAP
see also
Generally LPC family was never so popular, I have 2-3 development boards with some member of LPC but I never used them beyond blink led example.
IMO, DAP42 gets bonus points for being more open.
IMO, DAP42 gets bonus points for being more open.
I find drag and drop convenient, but certainly not a requirement.
The CMSIS-DAP code is fairly self-contained and small – it would need few modifications except for some locking to prevent GDB and CMSIS-DAP from trying to simultaneously control the SWD port.
I find drag and drop convenient, but certainly not a requirement.


