Sino:bit Test drive & attempt to single-step debug with OpenOCD and GDB

Sino:bit - Arduino, OpenOCD and GDB?

A little while back, I responded to an offer to get a free Sino:bit from the nice folks at Elecrow. Well, it was not completely free; I paid $4 for shipping from China, as it was not really practical for me to pick it up. ;)

In case you've not heard - this is the Chinese version of the BBC Micro:bit - or more precisely, based on the Calliope mini, which is based on the Micro:bit. Me... I'm in favor of pretty much any technology that may help inspire the next generation of programmers.

Although there are a variety of ways to program this device, I followed along with the Adafruit instructions to use the Arduino IDE (and/or the VisualMicro add-in for Visual Studio).

Initial programming was really quite easy. There was one little instruction missing from the Adafruit site. Hopefully they will notice my tweet and make the correction. In short, the Arduino HT1632 libraries need to be manually added. So if you see an error like this:

...then simply add the library:

I like to turn on verbose compiling and uploading:

When doing so, a successful upload will look like this:

In particular, I noticed that a forked version of Open OCD is used to upload the sketch. The first thing that comes to mind when mentioning OpenOCD, is of course GDB! So I thought I'd see if I could get some single-step debugging working without the need for a potentially expensive hardware debugger.

One line to notice during the verbose compile / upload is the last line of the compile. Note that a unique directory is created for the binaries. In my case: ~\arduino_build_91191

The full line from my Arduino IDE looked like this:

C:\Users\gojimmypi\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/cmsis-dap.cfg -c ; -f target/nrf51.cfg -c program {{C:\Users\GOJIMM~1\AppData\Local\Temp\arduino_build_91191/sinobit.ino.hex}} verify reset; shutdown; 

In order to launch OpenOCD to simply listen, and not upload - minor modifications are needed. Remove everything after and including the "-c program":

C:\Users\gojimmypi\AppData\Local\Arduino15\packages\sandeepmistry\tools\openocd\0.10.0-dev.nrf5/bin/openocd.exe -d2 -f interface/cmsis-dap.cfg -c ; -f target/nrf51.cfg  

Upon launching this in a DOS window, the resulting output looks like this:

Note that OpenOCD will not exit. It is waiting and listening for a GDB connection.

In my case, I could not find a suitable Windows GDB executable. So I ventured into the land of WSL - specifically Ubuntu. (I also wrote a little blog on OpenOCD on WSL Ubuntu). Once a local Ubuntu is installed an operational, GDB can be added:

sudo apt-get install gdb

Note that in WSL Ubunto, there's no C:\ drive and the slashes all go in the opposite directions. I went to my specific directory created by the Arduino IDE:

cd /mnt/c/Users/gojimmypi/AppData/Local/Temp/arduino_build_91191

GDB is launched like this:

gdb -d ./ -d /mnt/c/Users/gojimmypi/AppData/Local/arduino15/packages/sandeepmistry/hardware/nRF5/0.4.0/cores/nRF5 -f sinobit.ino.elf

If all goes well, when GDB is running and accepting commands, if will look something like this in the WSL Ubuntu window:

Due to the oddities of Windows vs Linux, I first ran these commands:

# C:\ is found in /mnt/c
set substitute-path c:/ /mnt/c

# There was an odd case problem in Arduino15 vs arduino15
set substitute-path /mnt/c/Users/gojimmypi/AppData/Local/Arduino15/ /mnt/c/Users/gojimmypi/AppData/Local/arduino15/

# make really sure the current directory is used
directory ./

Then connect:

target remote localhost:3333
monitor reset init

The resulting GDB window in Ubuntu should look something like this:

The OpenOCD DOS window should have updated, and look something like this, showing the successful connection:

At this point, things are really exciting! Ready to debug? Sadly, no. Typing the GDB "step" command results in the dreaded message:

Cannot find bounds of current function

I also tried to use the VisualMicro add-in for Visual Studio, no joy there, either:

Although it certainly works to compile and upload code in "release" (no single-step debugging) mode:

@TheFlyingSephyr also suggested trying the Embedded Studio IDE with the Segger hardware debugger. Perhaps another blog for another day...

On a side note, it might me interesting to peek at the elf file:

sudo apt-get install binutils
readelf -a /mnt/c/Users/gojimmypi/AppData/Local/Temp/arduino_build_91191/sinobit.ino.elf

In the end, it seems that you simply can't get to there from here when attempting to debug a "soft device".  :| If you have any ideas, please leave a comment or send me a message at gmail.

UPDATE: I've had a few replies regarding other debugging options. In particular a tweet from Tomas indicating that perhaps Mbed tools might help. Indeed there's some interesting info that shows using arm-none-eabi-gdb and pyOCD. Although I was able to get that toolchain installed and working:

I was not able to actually get single-step debugging working (nor does the Mbed instruction page indicate this is even possible). Note the error:

(gdb) step
Warning:
Cannot insert hardware breakpoint 0.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

As show here:

Another more promising method (although considerably more complex and potentially expensive) - would be the hardware debugging method using JTAG. One of the key things needed here is of course is how to connect the debugger. Many thanks to Elecrow for the prompt reply on twitter for information on the Sino:bit JTAG pins:

What you cannot immediately see from the silkscreen is that those are pads and not through-holes. Another item on my wish list for version 2! (ok, let's make the proper wish: how about a actual header for JTAG connector!)

I'll create another blog page for the Sino:bit JTAG. My first attempt will be using my $2 Blue Pill STM32F103 board converted to a Black Magic Probe.

Overall the Sino:bit seems very cool, despite the problems with OpenOCD and GDB. It would be awesome if some sort of single-step debugging was possible - bit that certainly is not a showstopper. Most people, certainly not beginners - would never even attempt this type of debugging. Other changes I would make would be having a less intensely bright power LED, and making the 12 x 12 grid of LED's multi-color.


Resources, Inspiration, Credits, and Other Links:

• github - sinobit hardware
• StackExchange - How do I debug a Arduino Uno with gdb on a Linux pc?
• https://github.com/sandeepmistry/arduino-nRF5#selecting-a-softdevice
• Bash for Windows colors are unreadable with default terminal theme #7556
• GDB - Specifying Source Directories
• GDB - Setting Breakpoints
• stackoverflow.com: Why I do get “Cannot find bound of current function” when I overwrite the ret address of a vulnerable program?
• Nordic Developer Zone: debugging softdevice applications with gdb
• going beyond the arduino ide
• forum.arduino,cc - How do I use a Makefile?
• Compiling Arduino sketches using Makefile
• github sudar/Arduino-Makefile
• arm MBED CMSIS DAP
• Nordic Semiconductor adds Embedded Studio IDE support for nRF51 and nRF52 SoC development

Converting a Blue Pill STM32F103 board to a Black Magic Probe

Recently, I learned about the really awesome Black Magic Probe - an interesting JTAG and SWD adapter that essentially has its own, built-in OpenOCD server... so you can use only the GDB client to connect directly to this device for debugging! I've been meaning to place an order for one, but then I ran across this article that converts an STM32F103 "Blue Pill" board to a Black Magic Probe!

Edit: I also tried to use the Maple Mini clone, like this one unsuccessfully; Although I was able to flash the bootloader, my computer did not recognized the device when plugged into the mini-USB connector. (apparently I'm not the only one that was unsuccessful with this).

The instructions there appear very straightforward, however as soon as I saw the some of the text, I realized the guy was using a slightly different distro of linux. So I'll add my notes on using Ubuntu. My Ubuntu is in a VMWare Workstation Virtual Machine running on Windows 10. If you have a similar setup - just don't forget to connect the device as needed from host in VM - Removable Devices. The WSL Ubuntu on Windows that I have still does not yet recognize all USB devices.

Another significant issue for me turned out to the fact that the STM32F103C8T6 is (debatable: see my comment here and noted by someone else here) only a 64K device (8K for bootloader leaving 56K for app)... and the Black Magic Probe now compiles to 57K. If it was easy, it would be no fun, eh?

To get started, ensure the tool chain is installed:

sudo apt-get update
sudo apt-get install git --assume-yes
sudo apt-get install gcc-arm-none-eabi --assume-yes
sudo apt-get install dfu-util --assume-yes

cd ~/
mkdir -p workspace
cd ~/workspace/
git clone https://github.com/jsnyder/stm32loader.git # download stm32loader
git clone --recursive https://github.com/blacksphere/blackmagic.git # download Black Magic source
#git clone --recursive https://github.com/rogerclarkmelbourne/Arduino_STM32.git # optional, has stm32flash
# optional stm32flash (64 bit version)
mkdir -p tools
cd tools
wget https://github.com/rogerclarkmelbourne/Arduino_STM32/raw/master/tools/linux64/stm32flash/stm32flash
chmod +x stm32flash
cd ~/workspace/blackmagic
make
cd src
make clean && make PROBE_HOST=stlink

when all looks good, see if you can talk to your board:

sudo apt-get install python-serial
sudo chmod 777  /dev/ttyUSB0
cd ~/workspace/blackmagic/src/
python ~/workspace/stm32loader/stm32loader.py -p /dev/ttyUSB0

it should return a result like this:

Bootloader version 22
Chip id: 0x410 (STM32 Medium-density)

Ready to flash! However - note that this is where my instructions are different.

cd ~/workspace/blackmagic/src/
python ~/workspace/stm32loader/stm32loader.py -p /dev/ttyUSB0 -e -w -v blackmagic_dfu.bin

The first time I tried, there was an error (also not the jumper setting needed for BOOT0=1:

Can't init. Ensure that BOOT0 is enabled and reset device
Traceback (most recent call last):
  File "/home/gojimmypi/workspace/stm32loader/stm32loader.py", line 436, in 
    bootversion = cmd.cmdGet()
  File "/home/gojimmypi/workspace/stm32loader/stm32loader.py", line 118, in cmdGet
    if self.cmdGeneric(0x00):
  File "/home/gojimmypi/workspace/stm32loader/stm32loader.py", line 115, in cmdGeneric
    return self._wait_for_ask(hex(cmd))
  File "/home/gojimmypi/workspace/stm32loader/stm32loader.py", line 88, in _wait_for_ask
    raise CmdException("NACK "+info)
__main__.CmdException: NACK 0x0

So just as the error hint said, I pressed the reset button and tried again. Success! Output looks like this:

Bootloader version 22
Chip id: 0x410 (STM32 Medium-density)
Write 256 bytes at 0x8000000
Write 256 bytes at 0x8000100
  [..snip..]
Write 256 bytes at 0x8001900
Write 256 bytes at 0x8001A00
Read 256 bytes at 0x8000000
Read 256 bytes at 0x8000100
  [..snip..]
Read 256 bytes at 0x8001900
Read 256 bytes at 0x8001A00
Verification OK

DFU loader done! Be sure to move jumpers back to default of "0" and press reset again. The instructions that I followed indicated that the USB device should be disconnected and reconnected. Not much interesting or different there upon re-insertion. Device is still a cp2104 on /dev/ttyUSB0

[927124.098974] usb 2-2.1: new full-speed USB device number 18 using uhci_hcd
[927124.418782] usb 2-2.1: New USB device found, idVendor=10c4, idProduct=ea60
[927124.418783] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[927124.418784] usb 2-2.1: Product: CP2104 USB to UART Bridge Controller
[927124.418785] usb 2-2.1: Manufacturer: Silicon Labs
[927124.418786] usb 2-2.1: SerialNumber: 012345678
[927124.424936] cp210x 2-2.1:1.0: cp210x converter detected
[927124.433135] usb 2-2.1: cp210x converter now attached to ttyUSB0 

The first time I ran dfu-util:

dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D blackmagic.bin

I received an error:

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
dfu-util: No DFU capable USB device available

I had 2 new devices: /dev/serial and /dev/ttyUSB0 when plugged in.

The reason for the error? I missed the MOST IMPORTANT PART:

Disconnect everything and use the USB to connect.

The Black Magic probe uses the micro USB connector, NOT the Serial TTL! (oops) Sure enough, the device is now listed in Device Manager:

A word of caution here: if you happen to use different sources of power, beware of ground loops. I highly recommend only 1 source of power (either the USB TTY/UART or onboard Micro USB. This could be particularly important if they are on different physical computers, using a USB hub, etc.

When you remove the TTY/UART and connect the USB port on the Blue Pill, you should see something like this with dmesg:

[937218.226791] usb 2-2.1: USB disconnect, device number 22
[937218.227053] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[937218.227064] cp210x 2-2.1:1.0: device disconnected
[937223.643635] usb 2-2.1: new full-speed USB device number 23 using uhci_hcd
[937223.959267] usb 2-2.1: New USB device found, idVendor=10c4, idProduct=ea60
[937223.959269] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[937223.959271] usb 2-2.1: Product: CP2104 USB to UART Bridge Controller
[937223.959272] usb 2-2.1: Manufacturer: Silicon Labs
[937223.959273] usb 2-2.1: SerialNumber: 01234567
[937223.967154] cp210x 2-2.1:1.0: cp210x converter detected
[937223.973711] usb 2-2.1: cp210x converter now attached to ttyUSB0
[937258.140246] usb 2-2.1: USB disconnect, device number 23
[937258.144289] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0
[937258.144327] cp210x 2-2.1:1.0: device disconnected

[938012.539892] usb 2-2.1: new full-speed USB device number 24 using uhci_hcd
[938012.886453] usb 2-2.1: New USB device found, idVendor=1d50, idProduct=6017
[938012.886455] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[938012.886472] usb 2-2.1: Product: Black Magic (Upgrade) for STLink/Discovery, (Firmware v1.6.1-43-g984f8b3)
[938012.886474] usb 2-2.1: Manufacturer: Black Sphere Technologies
[938012.886474] usb 2-2.1: SerialNumber: 76543210

Unfortunately dfu-util -l is not happy:

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Cannot open DFU device 1d50:6017

To confirm the device is there,lsusb shows the device as "OpenMoko":

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 025: ID 1d50:6017 OpenMoko, Inc.
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

You can also view just the device you are looking for with the -d parameter:

lsusb -d 1d50:

(don't forget the trailing colon ":"!

Ok, not obvious - but the problem here is one again permissions. So run the command with sudo:

sudo dfu-util -l

If successful, the output should look like this:

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

Found DFU: [1d50:6017] ver=0100, devnum=27, cfg=1, intf=0, alt=0, name="@Internal Flash /0x08000000/8*001Ka,056*001Kg", serial="76543210"

Once you can see the device, run dfu-util with sudo:

sudo dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D blackmagic.bin

I received an error, that sure looks like an out of memory issue:

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:6017
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08002000, size = 58364
dfu-util: Last page at 0x080103fb is not writeable

So I found other instructions relating to STM Discovery as a Black Magic Probe that indicated dfu_upgrade.bin needed to be loaded (I was willing to try anything!)

sudo dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D dfu_upgrade.bin

The results are a bit more promising:

dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to dfu-util@lists.gnumonks.org

dfu-util: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release!!!
Opening DFU capable USB device...
ID 1d50:6017
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 1024
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x08002000, size = 6764
Download        [=========================] 100%         6764 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state

But even with that - I was completely unable to use dfu-util to program the Blue Pill with a 57K blackmagic.bin file. Even after power cycle, reset, etc. So I put the board back into USART programming mode (BOOT0 jumper=1, BOOT1 jumper=0) and used the ST Flash Loader app on Windows. The device is initially detected as a 65K device:

However on the next screen, apparently you can force it into 128K mode:

The select the blackmagic.bin file, click the "Erase necessary pages", select an address of 0x8002000 and check the "Verify after download" checkbox:

If successful, you should see:

I should point out that several times I received a verify error at this last verify step (I was really convinced I had a 64K-only device). After trying again the next day - things started working immediately and I never again saw the verify error, even after doing a full erase and starting over. YMMV.

Keep in mind that the fact that we are using 128K on a 64K device is rather dangerous. In all likelihood, the manufacturer does an exhaustive memory test: throws away the ones with an error in the first 64K, market the ones with an error in the second 64K as only a 64K STM32f103C8T6 device, and label the ones with no error as 128K STM32f103CBT6 devices. Although this may be a fun Saturday afternoon project, if you are serious about actually using and depending on a BlackMagic probe for real debugging, consider buying one. (besides, always good to support the developer).  When you are elbows-deep in debugging your own project, you really don't want a questionable debugger.

So at this point, I'm not even sure the dfu bootloader is needed, if we are loading the blackmagic.bin file this way.

My particular debugging experiment uses the STM Smart V2 board as a target, and using my STM32 to ST7735 TFT LCD display example with the source on github. This is somewhat of a convoluted setup, as the project is in Visual Studio 2017 (on Windows 10) with the VisualGDB Extension from Sysprogs.

As previously mentioned, I'm running my Ubuntu in a VM, and I have samba installed so that on Windows I can map a drive  (C$ is root  /):

net use z: \\192.168.1.30\c$ /user:gojimmypi

Debugging connections from Blue Pill board configured as a Black Magic Probe (micro usb connected to Ubuntu):

Connecting the Blue Pill Black Magic Probe to an STM Smart V2 board:

cd  ~/workspace
git clone https://github.com/gojimmypi/STM32-ST7735.git

then open the solution Z:\home\gojimmypi\workspace\STM32-ST7735\STM32-ST7735.sln in Visual Studio and compile.

cd  ~/workspace/STM32-ST7735/STM32-ST7735
arm-none-eabi-gdb -d ./ -f ~/workspace/STM32-ST7735/VisualGDB/Debug/STM32-ST7735 -tui
ls /dev/ttyACM* -al

then in GDB, connect with the first ttyACM[n] device (the second one is a serial port). Mine were originally ttyACM0 and ttyACM1, but then later changed to ttyACM1 and ttyACM2 (no idea how/why). I even saw an instance while debugging that ttyACM1 changed to ttyACM0 yes leaving me with (ttyACM0 and ttyACM2).Weird.
Anyhow, here are some useful GDB commands to get started:

target extended-remote /dev/ttyACM1
monitor swdp_scan
attach 1

If successful you should see something like this:

GNU gdb (7.10-1ubuntu3+9) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/gojimmypi/workspace/STM32-ST7735/VisualGDB/Debug/STM32-ST7735...done.
(gdb) target extended-remote /dev/ttyACM1
Remote debugging using /dev/ttyACM1
(gdb) monitor swdp_scan
Target voltage: unknown
Available Targets:
No. Att Driver
 1      STM32F1 medium density
(gdb) attach 1
Attaching to program: /home/gojimmypi/workspace/STM32-ST7735/VisualGDB/Debug/STM32-ST7735, Remote target
0x08001514 in SetSysClockTo72 () at system_stm32f10x.c:993
(gdb)

sample

Resources, Inspiration, Credits, and Other Links:

• Converting an STM32F103 board to a Black Magic Probe (Param Aggarwal) 
• 1bitsquared Black Magic Probe (BMP)
• 1bitsy and Black Magic Probe on Kickstarter
• https://github.com/blacksphere/blackmagic
• blackmagic stlink clone support issue #62
• Atmel DFU Bootloader Datasheet
• STM32F103x8 / STM32F103xB data sheet
• stm32loader (jsnyder repo on github)
• STM Discovery as Black Magic Probe
• stm32duino - Black Magic Probe on an stm32f103c8
• stm32duino - dfu-util: Cannot open DFU device
• STM32 Flash loader demonstrator (UM0462)
• wiki.stm32duino Blue Pill
• Writing internal flash with dfu-util to set EEPROM defaults
• STM32 Smart V2.0
• https://github.com/rogerclarkmelbourne/Arduino_STM32
• wifi4things - STM32F103C8T6 Blue Pill Board with Arduino IDE on Linux (pics broke, but interesting info)
• https://wiki.paparazziuav.org/wiki/STLink

More on Segger J-Link and VisualGDB.

In my previous post, I explained the problem of J-Link JTAG drivers being changed by OpenOCD in VisualGDB, and my difficulty in putting back the proper drivers for use by Segger utilities.

Since posting this information to twitter and sysprogs forums, I've learned some interesting (and cool) things:

1) The clever folks at Sysprogs have their own "zadig-like" USB driver tool (strategically called USBDriverTool), that unlike zadig, has a "put back the original drivers" feature:

And can be downloaded (free!) here:

http://visualgdb.com/UsbDriverTool/

2) Additionally - the kind support folks at Segger responded to my email and pointed out that VisualGDB also supports talking to the Segger GDB server directly (instead of using OpenOCD). There's even an excellent example:

https://visualgdb.com/tutorials/arm/stm32/

Note in particular that instead of picking the J-Link device from the OpenOCD Debug method drop-down list, that there's a "J-Link JTAG" debug method also listed!

3) The Segger folks also have an explanation on the J-Link showing up as a BULK device in Windows. This is not a problem I had, but I am including this as relevant:

https://wiki.segger.com/J-Link_shown_as_generic_BULK_device_in_Windows

The screen snips there appear to be from an earlier version of Windows. Additionally, as noted in my proir post - simply selecting "Update Driver" would result in Windows saying that the drivers are already the current ones (even though it does not work). So you may need to delete the drivers before attempting the update when seeing this "BULK" driver issue.

ESP8266 JTAG Debugging in Visual Studio with Segger J-Link and Sysprogs VisualGDB

My go-to development tool so far for the ESP8266 is still the Visual Micro add-in for Visual Studio. It is however a pure software environment, that supports breakpoints, but in a different way. It is also a little odd in the way that it uses the Arduino environment - yes, in Visual Studio. But it works. Reliably. Consistently.

With my newfound confidence in getting J-Tag debugging working with the Olimex ESP8266 I decided to revisit the first unit I bought - the Segger J-Link.

Let's first start by noticing the ESP8266 is nowhere to be found on the Segger supported device list page.  But it is a standard JTAG device that when adhering to standards, Should work, no? Besides, I always enjoy a challenge.

It is cool Segger has an EDU (Educational) version for only $60(USD).  A large discount over their base unit of $378, and massive discount compared to their $1000 J-Link Pro, (with of course different capabilities). Here's a screen snip from their web site comparing versions.  (or visit the Segger Model Overview page for a more detailed comparison).

I really like that the EDU version is available to any hobbyist, not just students - just provided that you are not using it to make a commercial product for profit. Segger explains more on the terms of the EDU version on their web site. One thing to note is that there's no support other than forum questions.

The Olimex ARM-USB-OCD-H/ unit is also available for about $60 from Mouser Electronics - but they do not appear to have other more advanced units with more features. The Segger with Ethernet could be a really cool device to have one day....

So yes, I'm over $120 into a couple of hardware debuggers that I intend to use with a $3 ESP8266.

I first tried connecting my Segger to a NodeMCU with no success. VisualGSB seemed happy with the JTAG interface at project setup / test time, but not when actually programming.

For an easy increment step - I'll revisit prgramminh the $9 Olimex ESP8266 EVB shown in the SysProgs VisualGDB ESP8266 Tutorial, using the same pins:

The first thing that was immediately obvious, is that I like the Olimex having its own 5V power supply for their EDP8266 EVB board. The Segger does not have a power supply connector, however on page 420 of the J-Link manual - "Pin 19 of the connector can be used to supply power to the target hardware. Supply voltage is 5V, max. current is 300mA. The output current is monitored and protected against overload and short-circuit. Power can be controlled via the J-Link commander". I could not find the specs on the ESP8266-EVB (surely it is less than 300mA, eh?) - but I used a separate power supply for the Olimex ESP8266-EVB.

For reference: Pages 418 and 419 of the Segger manual* shows this table of JTAG pin definitions:

* (I've requested permission from Segger to include this)

As noted in my previous blog, I am following the Syslogs VisualGDB ESP8266 OpenOCD tutorial.

Success! The Segger *does* work in the same way as the Olimex ARM-USB-OCD-H to debug the ESP8266 - but my target is still the Olimex ESP8266-EVB.  I really want to get debugging working on the NodeMCU as noted in this long and winding forum topic.

ESP8266 JTAG Debugging in Visual Studio with Olimex ARM-USB-OCD-H and Sysprogs VisualGDB

To date, my go-to development environment - in Visual Studio 2015, is the VisualMicro add-in. There's no hardware debugging, but I've found it easy to use and reliable.

However, I've been interested on getting JTAG ESP8266 hardware debugging working in Visual Studio using the Sysprogs VisualGDB add-in - with mixed results.

I started with the Altera Bus Blaster than I already had on hand for programming Arduino. (hint: don't bother, it won't work: no reset control - see this discussion )

There are several tutorials, some not really up to date, but each with interesting information:

Developing projects for the ESP8266 WiFi chip with Visual Studio - August 24, 2015
Debugging ESP8266 firmware with Olimex ARM-USB-OCD-H - September 9, 2015
Debugging ESP8266 firmware with the UART GDB Stub - October 14, 2015
Debugging ESP8266 code with OpenOCD and Visual Studio - November 5, 2015

First, just figuring out which JTAG debugging hardware to buy: first I tried the Segger (kudos to them for having a generous discount for people not developing to sell a product). The Sysprogs folks then recommended that I follow the tutorial exactly, by using an Olimex instead. Another week into my 30 day trial and Mouser Electronics to the rescue with an ARM-USB-OCD-H debugger delivered. The price was about the same as the EDU version of the Segger. (approx. $60)

I had problems even finding the ESP8266 Xtensa-LX 106 elf for GDB stub (hint, it does not display in the directory shown in tutorial!) 

I also had problems with the interesting feature to debug existing project.

In the end I did get the debugging working.

I have this video on Creating Olimex VisualGDB Embedded Project for ESP8266 :

and this video on JTAG Debugging ESP8266 with Olimex and VisualGDB

 (they are separate as Windows 10 feature "Windows Key + G" video recording does not record pop-up dialog boxes)

Here are the pinouts of the Olimex ARM-USB-OCD-H 20-pin JTAG connector and the Olimex ESP8266-EVB ESP8266 10 pin header:

Here's also a partial Olimex schematic of interest:

My setup looks like this:

Now that I have this working with the Olimex version of the ESP8266... on to trying to do this with the NodeMCU version!

I'll be posting updates on twitter with source code on GitHub.