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

devan
Posts: 42
Joined: Sat May 14, 2016 1:45 am

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

Post by 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?
I've already released it as open source (that was one of the requirements for getting the USB PID allocated). It covers the core functionality I want (you can debug stuff and read serial data), but I still have some plans to add extra features to make it closer to parity with an mbed HDK chip.

For fun, I also tried my hand at trimming down the BMP firmware. Even with only one target (STM32F1x chips) and stripping out ~3KB of embedded XML, I still can't get it below ~45KB.

If having the GDB remote server protocol is not a firm requirement, debugging with OpenOCD connected to a CMSIS-DAP debug probe is only a little bit more complicated than with the BMP.

gbulmer
Posts: 67
Joined: Wed Sep 23, 2015 12:04 am
Location: UK

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

Post by 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).
Woooh! May I ask where?
devan wrote:It covers the core functionality I want (you can debug stuff and read serial data), but I still have some plans to add extra features to make it closer to parity with an mbed HDK chip.
Does it support the mbed's 'it looks like a flash drive, so upload is just a host Operating System copy'?

I think this is a key feature that makes the mbed friendly to almost everyone.
devan wrote:For fun, I also tried my hand at trimming down the BMP firmware. Even with only one target (STM32F1x chips) and stripping out ~3KB of embedded XML, I still can't get it below ~45KB.
Thanks for independent confirmation. I think I get it :), a 64kiB device is essential for BMP!
devan wrote:If having the GDB remote server protocol is not a firm requirement, debugging with OpenOCD connected to a CMSIS-DAP debug probe is only a little bit more complicated than with the BMP.
My 'knee-jerk reaction' is every extra piece of technology that has to be installed, debugged, and maintained is an extra hurdle that some people (and organisations) will fall at.

Our main users are in education. That is schools, colleges, and universities. They have to deploy at scale. They may have conflicting or incompatible IT needs. IT services is often understaffed. Each piece of technology that can be removed is a useful benefit. KISS!

Right now, 'USB flash upload' and debug messages over the same USB cable are a minimum. Upload via 'USB flash' removes one piece of complexity that stymies Arduino. If the USB connection can be read and written like a simple USB CDC serial device, so the Arduino IDE serial monitor and simple C/Python programs can interact with the device, then that is a likely enough.

I would desperately like a proper debugger, but almost no one in the traditional Arduino-world has it.

I don't imagine I'll get to this until late summer, or next year if we get busy. So I have plenty of time to mull.

Thank you very much for your help and advice.
You and Rick have given us a lot more than I had hoped.

devan
Posts: 42
Joined: Sat May 14, 2016 1:45 am

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

Post by 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).
Woooh! May I ask where?
Firmware source and hardware designs are up on GitHub:
https://github.com/devanlai/dap42
https://github.com/devanlai/dap42-hardware
gbulmer wrote:
devan wrote:It covers the core functionality I want (you can debug stuff and read serial data), but I still have some plans to add extra features to make it closer to parity with an mbed HDK chip.
Does it support the mbed's 'it looks like a flash drive, so upload is just a host Operating System copy'?

I think this is a key feature that makes the mbed friendly to almost everyone.
I haven't made too much progress on that front. I was going to implement it a different way, but it didn't work out as cleanly as I had hoped, so I might just borrow the mbed mass-storage implementation.
gbulmer wrote:
devan wrote:If having the GDB remote server protocol is not a firm requirement, debugging with OpenOCD connected to a CMSIS-DAP debug probe is only a little bit more complicated than with the BMP.
My 'knee-jerk reaction' is every extra piece of technology that has to be installed, debugged, and maintained is an extra hurdle that some people (and organisations) will fall at.

Our main users are in education. That is schools, colleges, and universities. They have to deploy at scale. They may have conflicting or incompatible IT needs. IT services is often understaffed. Each piece of technology that can be removed is a useful benefit. KISS!
That's a fair requirement, though as a counterpoint, if you need to update the GDB portion of the BMP, it'll probably be a lot more work to deploy a DFU firmware upgrade than to roll out a new version of OpenOCD software.
gbulmer wrote: Right now, 'USB flash upload' and debug messages over the same USB cable are a minimum. Upload via 'USB flash' removes one piece of complexity that stymies Arduino. If the USB connection can be read and written like a simple USB CDC serial device, so the Arduino IDE serial monitor and simple C/Python programs can interact with the device, then that is a likely enough.

I would desperately like a proper debugger, but almost no one in the traditional Arduino-world has it.
I agree; that's part of why I started working on my debugger as a side project - to bring some of the mbed-style features to everyone in a cheap, beginner-friendly TSSOP-20 package. It remains to be seen whether the mass-storage will actually fit in the remaining 16KiB I have to work with.

jonr
Posts: 14
Joined: Sun May 08, 2016 2:06 pm

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

Post by jonr » Fri May 27, 2016 5:57 pm

I would be interesting to compare this to IBDAP.

User avatar
Rick Kimball
Posts: 862
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

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

Post by 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.
-rick

jonr
Posts: 14
Joined: Sun May 08, 2016 2:06 pm

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

Post by 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.

User avatar
RogerClark
Posts: 5951
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

Post by 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
Posts: 42
Joined: Sat May 14, 2016 1:45 am

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

Post by 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/
x893's implementation is probably better tested for various STLink targets (both legitimate and knockoff), since it's been around for quite a while now. I literally only just ported my firmware to work with the STM32F103 this month (actually, the ST-LINK V2 clones I have use STM32F101 chips...).

Feature-wise, we're basically at parity - you get an ARM CMSIS-DAP 1.0 reference implementation + USB-CDC serial. The only difference is that my toolchain is around gcc-arm-embedded + libopencm3, whereas x893's uses Keil + ST libraries.

That said, as the author, I am a little biased towards my own work. I've been using reflashed knockoffs with my firmware which also turns the SWIM pin into an RX-only input for the USB-CDC connection, and it's worked great for me as a one-and-a-half-in-one debugging tool.
Rick Kimball wrote: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.
The LPC11Uxx isn't very popular for standalone boards, but it is one of the more accessible chips supported by the mbed interface firmware. I haven't tried it yet, but it's probably possible to reflash an IBDAP with the new SWDAP/DAPLINK firmware from mbed.

I would use the mbed firmware, except that I really want to get it to work on the STM32F042, so I would have to port it to use gcc-arm-embedded so that I can build it without buying a Keil/IAR license on top of porting it to the STM32 series.

As a segue back to the original topic, it might be possible to partner with mbed to port the mbed firmware to a different chip. However, I suspect that for most of their partners (NXP, ST, etc), hobbyist-friendly hand solderability is not a priority, since they're targeting professionally assembled development boards. The BBC micro:bit, for example, looks like it's all QFN.

User avatar
Slammer
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

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

Post by 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
Posts: 14
Joined: Sun May 08, 2016 2:06 pm

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

Post by 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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest