[Thoquz] wrote to us about an interesting GitHub project by [Valmantas Palikša] involving the porting of the Black Magic firmware to ESP8266. For those who are unaware, Black Magic Probe is firmware along with a range of official and third-party boards that targets the debugging of Cortex-M and Cortex-A MCUs and SoCs.
With this blackmagic-espidf project, one can use any ESP8266 board that has at least 2 MB of Flash program storage, though 1 MB should be possible if OTA updated are disabled. After flashing the firmware to the ESP8266 board, the GDB server can be reached on TCP port 2022 and UDP 2023, with a serial port available via TCP/23, UDP2323, or via the physical TX0/RX0 pins on the ESP8266.
The target board to be debugged is hooked up by default to GPIO0 (SWDIO) and GPIO2 (SWCLK) for Serial Wire Debugging, though JTAG is also said to be supported. If set up properly, next one should be able to pop into a fresh remote GDB session:
If you don’t want the WiFi, you can buy a wired one, or just roll your own from any STM32 board that you’ve got kicking around.
Noob question: what’s the advantage of this over target-specific debuggers or generic jtag/swd debuggers?
Wireless debugging, for example when debugging high voltage systems. The black magic debugger is open source (open hardware?)
BMP is running GDB on chip, meaning it can and should be more stable than openocd
Interesting. But will it work? AFAIK gdb serves quite small number of bytes (<5), but quite frequently. Not the best scenario for wifi.
Same issue around wifi_jtag and openocd:
https://github.com/emard/wifi_jtag
“There is much room for improvement of course: network protocol from OpenOCD could be optimized to allow longer packets, buffering, compression (instead of sending same sequence many times), use some hardware optimization in the ESP8266 like SPI as JTAG accelerator, or SVF player approach from JTAGWhisperer.”
The ESP8266 lacks USB support, the ESP32 does not have it neither, but the ESP32-S2 seems to have the possibility to have a CDC usb-serial mode without any usb-serial converter.
This however kind of voids sense of ESP port, native STM32 BMP already has it.
Not really, because openocd ends up bitbanging JTAG/SWD manually over the network link, which is hellishly slow.
But all the hardware access and low-level debug adapter layers are handled natively by BMP on the controller, only exposing a high-level gdbserver interface over the network. It’s not noticably different in speed to a wired debug adapter.
Works pretty ok. The GDB protocol transfers larger amounts of data (such as loading new firmware) efficiently, and smaller amounts of data such as “continue” or “breakpoint hit” are not *that* frequent.
Thank you for clarification. I will check this project for sure as soon as I finish my current one.
Ah but there is also a serial console available over TCP, so you could use the socat trick to map it to a local /dev/vmodem0 interface, something like:
$ socat pty,link=/dev/vmodem0,waitslave tcp:192.168.0.10:23
And then connect to it via screen or picocom.
See:
http://www.zoobab.com/esp8266-serial2wifi-bridge
Or you can just use an esp8266 module:
https://github.com/markrages/blackmagic/blob/esp8266/src/platforms/esp8266/Readme.md