Adding WiFi To Black Magic For Wireless GDB Action

[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:

gdb connection

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.

11 thoughts on “Adding WiFi To Black Magic For Wireless GDB Action

    1. 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.

      1. 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.

    2. 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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.