How about setting up debugging with BlackMagic Probe

One of the first debuggers to support Serial Wire Debug was a thing called Black Magic Probe (BMP). It has both custom hardware and an open source firmware component. Of interest to the STM32duino crowd is the fact that original platform is the stm32f103c8 chip. So in theory you could get it running on one of your ebay micro stm32f103 boards (note: not tried yet). This would provide an alternative to the stlink programmer debugger.

I think its best feature is that it presents itself as a serial device that talks the GDB Remote Serial Protocol device. This means you don’t need openocd or the texanne stlink stuff to talk to it. Even better is that it is just a CDC_ACM device so you don’t need special os drivers to interface to it. It shows up as a COMX: on windows or a /dev/ttyACMx on linux. Using arm-none-eabi-gdb -ex ‘target remote /dev/ttyACM0″ Blink.cpp.elf and you can load and debug your stm32 arduino programs. This also makes it easier to have a consistent debugger / programmer interface across different OS platforms.

You can read more about it here:

https://github.com/blacksphere/blackmagic/wiki

-rick

BTW: @roger, you might want to look at its DFU code to see how they deal with reset after loading new firmware

I looked at BMP before, it was (and still is) too expensive in my book. Ok, I appreciate hardware & development costs money, and even OSS engineers have to pay the bills.

But I can get a very nice $20 JTAG adapter and use it with emblocks, which all works out of the box.

I have been looking at creating a cross-programmer (using a spare target board as a programmer). The McHck guys have achieved that (solution specific to Freescale K20). Erich Styger is also looking into it, probably also K20 specific though.

Mbed have some code for OpenSDA, it’s in a state of flux though. It would involve a lot of re-inventing of the wheel though, and would make little difference in price (is all that effort worth $15?), and not really add any value over other offerings.

My conclusion here is that open source debugging (openocd, bmp etc) is a nice to have, but proprietary solutions are a more practical alternative. It’s hard enough getting a robust application API going!

Now that I re-read what I wrote it appears that I’m promoting the BMP hardware. I wasn’t trying to do that. Actually, I was trying to highlight that those $4 ebay chinese board and the BMP software would make a nice SWD programmer / debugger.

I compiled and loaded the opensource BMP firmware on an STM32F4 Discovery Board and used that to successfully program and debug with a few different ARM chips the NXP LPC1114 and LPC812 and an STM32F051. The STM32F4 firmware platform is already part of the source code. It is just a matter of compiling and loading it and then connecting some wires to your stm32 board. I’ve also installed BMP firmware on a TI stellaris board. That one also works and there is a fork of the BMP code you can download and install.

I find the idea of using the $4 clones and the BMP software to make a self sourced programmer / debugger the epitome of opensource being taken to its full potential. Sorry if I confused people with my first post.

-rick

Rick,

I have a STLink clone and also a JTag programmer (Clone).

I looked at BMP some time ago, but I agree with @bobc in that, the official BMP was too expensive for me.

I know that @ahull has stlink working with GDB command line interface, and I will look at the link you sent me to the stand alone Exclipse / GDB package

I’ll also look at the BMP clones, as if they are only $4 its worth buying one, just in case….

I looked at integrating JTag into the repo, but there seem to be various different manufacturers,
Also, I couldn’t get my JTAG to successfully upload and run a sketch. This is possibly because its a clone and may not even work correctly, but I’ve not had time to verify even whether my JTag is even uploading the code.

What I think will be almost a game changer is in circuit debugging. Trying to debug using Serial.print is painful.

I wonder what the IDE team were intending to do with the Zero, as even now the publicity material has things about in circuit debugging.

Edit.

Rick, can you send a link to one of those clones. I can’t find any

bobc wrote:I looked at BMP before, it was (and still is) too expensive in my book. Ok, I appreciate hardware & development costs money, and even OSS engineers have to pay the bills.

RogerClark wrote:Rick, can you send a link to one of those clones. I can’t find any

Rick

Thanks for those links.

It was a little unclear how I compile https://github.com/blacksphere/blackmag … orms/stm32

The top level makefile doesnt seem to have specific targets
So I don’t quite understand what its compiling, i.e the BMP firmware or something else

umm.

I’ll have to take another look

make PROBE_HOST=blah

where blah is one of the directories in blackmagic/src/platforms such as f4discovery or native or stlink or or swlink or tm4c

I think the stm32 directory is used by all the stm32 target platforms.

Thanks

I’ll try later…

Rick,

I’ve had a go at compiling BMP from the repo you linked to https://github.com/blacksphere/blackmagic, using Windows and MinGW

But libopencm3 won’t compile

I’ll give it a go tomorrow on Linux tomorrow

Unfortunatly that repo doesn’t compile under Linux either.

Lots of linker errors about code not fitting but also

cdcacm.c undefined reference to trace_buf_drain

I don’t think its worth trying to debug BMP.

Its easies just to use Texane-stlink, at least to start with albeit it uses prioprietary hardware.

I’m going to try to setup the Eclipse CDT Standalone debugger on a Linux machine, but it looks like I have to do a full install of Eclipse CDT first – shame the standalone debugger cant seem to installed “standalone”

I will let you know how I get on.

So I went ahead and made the BMP code work for the generic stm32f103c8 boards. You can find a downloaded that contains pre compiled binaries and source code here: http://www.stm32duino.com/viewtopic.php?f=37&t=122

I think I’ve done poorly in my attempts to explain why BMP is a good thing, I’m going to add some reasons why this is the best approach for both upload and debugging. Listed in no particular order (BMP == Black Magic Probe Firmware):

• BMP is a commercial product that happens to provide their code as open source.
• BMP takes the place of 3 binaries you are maintaining as part of this port.
  • You don’t need st-write because BMP will let you load files.
  • You don’t need the texanne/st-util on the host side to do debugging, the gdb server is built into the BMP firmware.
  • The DFU-Util isn’t required to put code on the board now.
  • The only required host side code is already provided (arm-none-eabi-gdb). It is part of the linaro arm gcc you get when you install the Due compiler.
• BMP isn’t proprietary like the ST-Link device. ST has never released the internal protocol for the ST-Link device. The texane code and openocd were able to add support after someone reverse engineered the usb protocol for st-link. This could change in the future.
• BMP provides both flash write upload and debug on the same interface.
• BMP provides a Virtual COM port for free. Those cheap ebay st-link clones don’t, they are st-link v2 not v2.1. When you use a virtual com port and a hardware USart on your Arduino code you benefit in these ways:
  • USBSerial in the libmaple isn’t free. It takes FLASH, RAM, and CPU cycles away from your code. It has to service the USB data and heartbeat requests on a very strict schedule and will take time away from with other interrupt handling.
  • When you reset your target board, you lose any Serial connections. If you are in a terminal emulator, it will go away.
  • The USBserial code uses RAM and Flash you could be using for your program. The USart code is much smaller and is only using CPU when data is sent or received. When no serial data is flowing, no cpu is used.
  • You don’t need to buy an FTDI/CH302/CP210x/PL2303HX/generic usb to serial dongle.
• You never have to twiddle boot pins to be able to program the device. BMP has the ability to connect under reset, which is like pulling the BOOT0 pin high.
• BMP was originally written on the stm32f103c series. This is the exact same hardware we are using.
• You can bootstrap your development environment from nothing. All the source code is available for everything.
• BMP is written using libopencm3. The libopencm3 project might be a good alternative to libmaple going forward. With the same API it supports more STM32 series than libmaple. In addition, it has also been ported to other ARM coretx-m chips from other vendors (NXP, TI).
• I’m sure I could come up with more if you aren’t convinced

Anyways, I’m going to modify platform.txt and boards.txt to support this.

-rick

I think for most people to be able to do this, you’re going to need to document in detail how to build BMP for various devices, and program the hardware as well as how to connect the BMP, and how to use it

This would need to be done for Windows as well as Linux, as the majority of users are on Windows

I’ve had very little feedback from my thread about how we can get a cross-platform version of a GUI to GDB, so I suspect at the moment not many people want to do this, or its just in the “too hard” basket.

Its a shame, because I think In Circuit debugging would be a huge benefit to everyone.

Its also a chicken and egg situation, I don’t think people are buying the hardware, e.g. STLink, (or another board to run BMP on), as at the moment there isn’t an easy way to use it. And… because hardly anyone has the hardware, there isnt much impetus to get he SW side sorted out.

My vision for this code is that people just buy one of those boards and upload the supplied binary to it using a serial device. The IDE would do the rest of the work. My goals are pretty limited right now. Step 1, provide a burn bootloader to a “BMP” programmer that does just that. Step 2, provide a menu item that lets you upload using BMP in addition to stlink and serial.

-rick

Rick

Sounds good. I did think about the Burn Bootloader option, but I’m not sure how thats patched into the IDE.

I took a look in the 3rd party spec doc https://github.com/arduino/Arduino/wiki … cification

and it was useless

Burn Bootloader

TODO…

But I see in the same doc it has

tools.avrdude.bootloader.pattern=[……] […..]

so I guess its a question of reverse engineering what the AVR does

Interestingly the IDE is really buggy about this, if you select an invalid combination of board and programmer you get a load of java messages

Error while burning bootloader.
java.lang.NullPointerException

etc
etc

which isn’t a good look