Is SWD-only BMP practical, and on Low-pin-count STM32?

gbulmer
Mon May 09, 2016 11:21 am
I’ve been idly pondering making a small hardware debugger based on the Black Magic Probe code. (This is a longer term project)

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?


Rick Kimball
Mon May 09, 2016 1:34 pm
I’ve only ever used the blue pill BMP as an SWD device with just 2 jumper wires and gnd. Not sure if those chips have enough flash though to hold all the code.

Slammer
Mon May 09, 2016 2:11 pm
I avoid to use crystal-less MCUs for applications with serial/usb communications. The STM32F070F6 may be a candidate for BMP, it has 32KB Flash and 6KB RAM, I think that this is enough. I dont know however the work required to adapt the firmware to the new MCU.

Rick Kimball
Mon May 09, 2016 2:48 pm
Slammer wrote:I avoid to use crystal-less MCUs for applications with serial/usb communications. The STM32F070F6 may be a candidate for BMP, it has 32KB Flash and 6KB RAM, I think that this is enough. I dont know however the work required to adapt the firmware to the new MCU.

Slammer
Mon May 09, 2016 11:59 pm
Thanks for the info Rick.
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.

gbulmer
Tue May 10, 2016 4:50 pm
Rick Kimball wrote:I’ve only ever used the blue pill BMP as an SWD device with just 2 jumper wires and gnd. …

devan
Sat May 14, 2016 2:01 am
I’ve been lurking for a while, but a DIY SWD-only debugger using the STM32F042Fx chip is one of my side projects, so I finally decided to register.

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.


Rick Kimball
Sat May 14, 2016 2:14 am
Nice stuff devan!

gbulmer
Sat May 14, 2016 10:24 pm
devan wrote:I’ve been lurking for a while, but a DIY SWD-only debugger using the STM32F042Fx chip is one of my side projects, so I finally decided to register.

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.


gbulmer
Sat May 14, 2016 10:33 pm
Rick Kimball wrote:I went through the code and removed all the logic required for JTAG and got rid of board support for chips I wasn’t going to use. I used a UART instead of the USB code which actually made it smaller. Even after all that code slash and burn I couldn’t get it to fit into 32KB. Any Cortex-M0 chip is going to use more code to do the same amount of work as an M3.

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


devan
Sun May 15, 2016 2:21 am
gbulmer wrote:
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?

gbulmer
Sun May 15, 2016 1:27 pm
devan wrote:I’ve already released it as open source (that was one of the requirements for getting the USB PID allocated).

devan
Sun May 15, 2016 5:37 pm
gbulmer wrote:devan wrote:I’ve already released it as open source (that was one of the requirements for getting the USB PID allocated).

jonr
Fri May 27, 2016 5:57 pm
I would be interesting to compare this to IBDAP.

Rick Kimball
Fri May 27, 2016 8:05 pm
Right off the bat it appears that you need a LPC11Uxx device to even use the software. I don’t know of any $4 lpc11uxx boards.

jonr
Sat May 28, 2016 2:19 pm
I agree – IBDAP is +$20 and I’m not aware of any advantages. DAP42 installed on a ST-LINK V2 clone sounds like a great option for a standards compliant debug adapter that will work with any ARM MCU.

RogerClark
Sat May 28, 2016 2:32 pm
Slightly off topic,

But one of the ST guys I spoke to at Maker Faire said he used this

https://github.com/x893/CMSIS-DAP

see also

https://mvdlande.wordpress.com/2015/10/ … i-adapter/


devan
Sat May 28, 2016 5:38 pm
RogerClark wrote:Slightly off topic,

But one of the ST guys I spoke to at Maker Faire said he used this

https://github.com/x893/CMSIS-DAP

see also

https://mvdlande.wordpress.com/2015/10/ … i-adapter/


Slammer
Sat May 28, 2016 8:05 pm
There was a version of LPC1114 in DIP28 package same years ago, but never gain popularity among hobbyist, now is a bit difficult to find it.
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.

jonr
Sat May 28, 2016 8:19 pm
The drag and drop feature in DAPLink requires custom flash writing code for each target processor. So it’s far from being a universal adapter that (fully) works with a large number of MCUs.

IMO, DAP42 gets bonus points for being more open.


devan
Sat May 28, 2016 9:07 pm
jonr wrote:The drag and drop feature in DAPLink requires custom flash writing code for each target processor. So it’s far from being a universal adapter that (fully) works with a large number of MCUs.

IMO, DAP42 gets bonus points for being more open.


jonr
Sat May 28, 2016 9:19 pm
I wonder if you could incorporate the flash writing code from open ocd/BMP/Versaloon/?? so that many MCUs would be supported on release.

I find drag and drop convenient, but certainly not a requirement.


devan
Sun May 29, 2016 5:01 pm
It would probably be much less effort to add a CMSIS-DAP interface to Versaloon/BMP instead.

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.


gbulmer
Sun May 29, 2016 11:55 pm
jonr wrote:

I find drag and drop convenient, but certainly not a requirement.


Leave a Reply

Your email address will not be published. Required fields are marked *