Olimex ARM-USB-OCD-H with OpenOCD - libusb_open() failed with LIBUSB_ERROR_NOT_S

[gojimmypi]

Greetings.

I have a new Olimex ARM-USB-OCD-H that I'd like to use to single-step debug ESP8266 in Visual Studio 2015 (V 14.0.25431.01 Update 3) with the VisualGDB (5.2) add-in as described here:

http://visualgdb.com/tutorials/esp8266/olimex/

However, I cannot even get past the "test settings" part of the Programming Interface selection. This is simply a call to OpenOCD, so I don't think it is a problem with VisualGDB nor Visual Studio. Instead I get an error: Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED

Code Select Expand


C:\SysGCC\esp8266\esp8266-bsp\OpenOCD\bin\openocd.exe -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f target/esp8266.cfg 
Open On-Chip Debugger 0.9.0 (2015-11-04-20:38)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
adapter speed: 1000 kHz
stop_wdt
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: esp8266.cpu: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : halted: PC: 0xffffffff
Info : debug cause: 0xffffffff
Info : accepting 'telnet' connection on tcp/4444
shutdown command invoked
Info : dropped 'telnet' connection


The interface/ftdi/olimex-arm-usb-ocd-h.cfg

Code Select Expand


#
# Olimex ARM-USB-OCD-H
#
# http://www.olimex.com/dev/arm-usb-ocd-h.html
#

interface ftdi
ftdi_device_desc "Olimex OpenOCD JTAG ARM-USB-OCD-H"
ftdi_vid_pid 0x15ba 0x002b

ftdi_layout_init 0x0908 0x0b1b
ftdi_layout_signal nSRST -oe 0x0200
ftdi_layout_signal nTRST -data 0x0100
ftdi_layout_signal LED -data 0x0800


and target/esp8266.cfg

Code Select Expand


set _CHIPNAME esp8266

transport select jtag

reset_config trst_and_srst

adapter_khz 1000

jtag newtap $_CHIPNAME cpu -irlen 5 -ircapture 0x1 -irmask 0x1f

set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME xtensa -endian little -chain-position $_TARGETNAME

# esp8266 seems to have a quirk where the JTAG hardware doesn't work
# at all for ~20ms after RST is released. We do a custom reset to
# avoid JTAG layer errors
proc init_reset {mode} {
        # assert both resets (SRST/TRST not a clear division on esp8266 anyhow)
        jtag_reset 1 1
        sleep 30
        jtag_reset 0 0

# wait for debug port to wake up
sleep 30

# validate scanchain
jtag arp_init
}


# Disable system watchdog when halted to avoid unexpected resets
$_TARGETNAME configure -event halted {
stop_wdt
}

proc stop_wdt { } {
mww 0x60000900 0
}


I'm using Windows 10 and Device Manager sees the Olimex device and is using C:\Windows\System32\drivers\WinUSB.sys version 10.0.14393.0 (rs1_release. 160715-1616)

Any suggestions as to what I am doing wrong? I've tried rebooting, other drivers via zadig. The selected drivers are the only ones that even allow the system to properly recognize the Olimex - yet I continue to see the error.

Thanks in advance. 

[JohnS]

Looking at the first 10 or so google results for that error strongly suggests it's a driver issue (I think the wrong one is getting the device) and it looks like trying to follow what others have done will work if you persist.

Windows just makes this hard.

libusb isn't getting to the actual device so there is nothing oocd etc can do until that part works.

John

[gojimmypi]

Hello & thanks for your reply. Yes, I saw the google results of the search as it relates to driver versions. The problem was VisualGDB kept insisting on its own specific version anytime I tried to change it.

As it turns out, that error can apparently be "safely ignored". See this response on the VisualGDB forum:

https://sysprogs.com/w/forums/topic/where-to-find-esp8266-xtensa-lx-106-elf-for-gdb-stub/#post-10206 - specifically:

The LIBUSB_ERROR_NOT_SUPPORTED error can actually be safely ignored. OpenOCD shows it as it first tries to connect to the 'Virtual COM port' part of the Olimex JTAG probe

And ya - I completely agree with your "Windows just makes this hard".

cheers

[JohnS]

Good news if you can just ignore it.... but... is it working?

Whenever I've had a scan of all ones it's not worked (though I'm not on Windows and not using esp8266 lol).

John

[gojimmypi]

Good news if you can just ignore it.... but... is it working?

yes, well - "working" seems to be a matter of perspective. Programmable? yes. Reliable single step? No. Breakpoints? Yes.

The diagnostics from the [test] button, even the JTAG "all ones" message apparently can be safely ignored.

I can program via the JTAG fairly quickly. Debugging? that's another story. Indeed I've been able to set breakpoints and single step via the JTAG interface. But it is a bit wonky. Sometimes the breakpoints are not hit.  Sometimes it gives repeated messages like:

Code Select Expand


Info : halted: PC: 0x402100d1
Info : debug cause: 0x2
Info : halted: PC: 0x402100d4
Info : debug cause: 0x1
Warn : Cannot set a software breakpoint at 0x402100d1. Trying a hardware one instead...

Often when I stop debugging, the chip is still in some sort of halted state - requiring a power cycle or reloading of firmware to resume.

The GDB output has some disturbing messages during upload, which appear during an odd visual presentation of a alternate flashing text output and the "uploading" progress bar (ignorable?):

Code Select Expand


@"xtensa_deassert_reset: 'reset halt' is not supported for Xtensa. Have halted some time after resetting (not the same thing!)\n"
...
-exec-continue
^running
*running,thread-id="all"
&"warning: \nUnrecognised function prologue. Stack trace cannot be resolved. This message will not be repeated in this session.\n"
&"\n"
~"\nProgram"
~" received signal SIGTRAP, Trace/breakpoint trap.\n"
~"0x4010013c in TimerFunction (arg=<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>) at LEDBlink.cpp:35\n"
~"35\t\t\tgpio_output_set(0, BIT1, BIT1, 0);\n"
*stopped,reason="signal-received",signal-name="SIGTRAP",signal-meaning="Trace/breakpoint trap",frame={addr="0x4010013c",func="TimerFunction",args=[{name="arg",value="<error reading variable: Cannot determine frame base. Please call the current function from a function compiled with frame pointer to allow viewing local variables.>"}],file="LEDBlink.cpp",fullname="C:\\workspace\\OLI5\\OLI5\\LEDBlink.cpp",line="35"},thread-id="1",stopped-threads="all"
-data-evaluate-expression "\*\(\(unsigned\ \*\)0x3fff8014\)"
^done,value="0"


then once loaded an debugging there are these messages:

Code Select Expand

...
-data-evaluate-expression "&__StackLimit"
^error,msg="No symbol \"__StackLimit\" in current context."
Cannot resolve the address of _estack. Skipping stack pointer validity check.
set *((int *)0x60000900)=$com_sysprogs_esp8266_wdcfg
&"set *((int *)0x60000900)=$com_sysprogs_esp8266_wdcfg\n"
=memory-changed,thread-group="i1",addr="0x60000900",len="0x4"
...



And this is all in the simple "blink" program with a breakpoint in the TimerFunction.

Simply running until a breakpoint seems to be the only reliable function. It will stop at a breakpoint. Single step after that? A roll of the dice. More often than not the dreaded "Frame not in module" appears. The crazy thing is that the debugger *is* still single stepping; clicking "view disassembly" and the source allows single stepping - but in assembly language. That could be super cool in certain circumstances. But not when simply trying to single step some C code.

There are frequent "GDB Timeout" dialog boxes on "-exec-continue". It never recovers from this. I need to cancel and completely stop debugging. Code is still not running in the device however.

While paused at a breakpoint, GDB gives odd messages (errors to be ignored?)

Code Select Expand

-var-delete "var2"
^done,ndeleted="1"
-var-create --frame 0 --thread 1 - * "ESP8266_GDBSTUB"
^error,msg="-var-create: unable to create variable object"
-var-create --frame 0 --thread 1 - * "gdbstub_init"
^error,msg="-var-create: unable to create variable object"
-var-create --frame 0 --thread 1 - * "gdbstub_init"
^error,msg="-var-create: unable to create variable object"
-var-create --frame 0 --thread 1 - * "gdbstub_init"
^error,msg="-var-create: unable to create variable object"
-var-create --frame 0 --thread 1 - * "gpio_output_set"
^done,name="var7",numchild="0",value="97 'a'",type="<variable (not text or data), no debug info>",has_more="0"
ptype/mt <variable (not text or data), no debug info>
&"ptype/mt <variable (not text or data), no debug info>\n"
&"A syntax error in expression, near `<variable (not text or data), no debug info>'.\n"
^error,msg="A syntax error in expression, near `<variable (not text or data), no debug info>'."
&"Quit (expect signal SIGINT when the program is resumed)\n"

(note the &Quit message shows up when pressing "Ctrl-C" to copy GDB output to clipboard)

The most reliable debugging method I have found is setting a single breakpoint, and running to it. While paused, remove that breakpoint - set a new one, and press "> Continue" button. The single step buttons don't seem to work.

Manually moving and/or creating multiple breakpoints in this manner allows for relatively robust and consistent results.

This tells me it is a software problem; If I can do this manually by moving or adding the breakpoint, why can't the VisualGDB software simply do this for me as I press the single-step or step-over button?

The ESP8266 is an exciting and inexpensive piece of hardware. I think there's a lot of potential in the VisualGDB software, but I have only 9 days left in my trial and so far I'm not super impressed. Supposedly it works better for devices other than the ESP8266. I'm not sure if I want to fork over $$ for the hope of improvement.

<edit>
Added videos for creating project: https://youtu.be/4Z1MnwWFzmA and debugging: https://youtu.be/9Hid7ixEigM
</edit>

[JohnS]

What has the support from the sellers (I suppose of VisualGDB) been like?

If they don't provide good support to get a sale it says a lot...

John

[gojimmypi]

What has the support from the sellers (I suppose of VisualGDB) been like?

If they don't provide good support to get a sale it says a lot...

Well, actually - the response on the VisualGDB forum (https://sysprogs.com/w/forums/) has been fairly good: polite and prompt - seemingly 7x24. So I have no complaints there.

[JohnS]

OK, so what have they said about the problem you just posted (Reply #4 this thread)?

John

[LubOlimex]

Most of the things that you mentioned are completely new for me, so your feedback and experience are highly appreciated.

It is not clear how good the OpenOCD support for ESP8266 is - all problems are probably purely software.

The one thing that I would recommend you to always investigate is the reset strategy set in the configuration files. I recommend you to test different reset strategies as mentioned in this chapter of the OpenOCD's manual: http://openocd.org/doc/html/Reset-Configuration.html

More specifically when using our OpenOCD debuggers, test with "reset_config srst_only srst_pulls_trst".

Best regards,
Lub/OLIMEX

[gojimmypi]

OK, so what have they said about the problem you just posted (Reply #4 this thread)?

John

The thread is here: https://sysprogs.com/w/forums/topic/where-to-find-esp8266-xtensa-lx-106-elf-for-gdb-stub/

Here's a video of my debugging experience: https://youtu.be/9Hid7ixEigM

In short - there are unknowns in the undocumented, proprietary portions of the ESP8266 and the results I see are expected.

useful responses from sysprogs forum copied here:

First of all, please note that ESP8266 and ESP32 debugging is extremely unreliable and random errors are very common.

We will try to clarify what is going on based on your description. The LIBUSB_ERROR_NOT_SUPPORTED error can actually be safely ignored. OpenOCD shows it as it first tries to connect to the 'Virtual COM port' part of the Olimex JTAG probe. If you get your breakpoint to hit, the problem is most likely not related to drivers or JTAG connections, but is caused by one of the tool limitations. We will try to outline them below.

The ESP8266 chip has undocumented watchdog mechanisms that can break debugging if the chip is stopped at a breakpoint for too long. Our OpenOCD port disables the known watchdog, but sometimes the chip still goes to an undebuggable state.

The chip also has only one hardware breakpoint, so you cannot set more than 1 breakpoint in FLASH code. Furthermore, when you step through the code with F10 or F11, gdb internally uses an extra breakpoint, so in order for that to work reliably, you need to remove all other FLASH breakpoints. We usually recommend moving the functions you want to debug to RAM.

Another problem is that the ESP8266 chip sometimes enters some undocumented state where it does not respond to debug requests via JTAG. This happens when using the AT command firmware, but may happen with other functions as well.

Our general recommendation would be to understand what debugging functionality works (e.g. setting breakpoints only in RAM) and rely on it to debug.

and

Thanks for the video. This is totally expected. In order to do reliable stepping, gdb needs 2 mechanisms:
1.To be able to step one instruction at a time
2.Once it steps into a function, it needs to set a breakpoint on either the first code line of that function (for stepping into) or on the first line after the calling line (for stepping over).

On ESP8266 both mechanisms don't work reliably:
1.Stepping instruction-by-instruction often triggers interrupts and gdb does not know how to step out of them
2.ESP8266 supports only 1 hardware breakpoint at a time, so if you already have one breakpoint in your code, gdb cannot set the temporary breakpoint as described above.

Additionally to that, gdb does not know how to reliably unwind the call stack on ESP8266, so if the target starts running some pre-built library code from Espressif, you see the 'frame not in module' message and don't get a meaningful call stack.

These issues don't happen with ARM devices because the ARM platform is very old and these problems were solved long ago. So for ARM devices, VisualGDB relies on the free tools like gdb to provide basic functionality (like stepping) and builds advanced features (like real-time watch) on top of them. For ESP8266/ESP32 there are no reliable low-level debugging tools and making them on our side would drive the VisualGDB price sky high (you would probably not want to pay $5K to debug a $2 chip), so unfortunately VisualGDB has to depend on the unreliable open-source tools that may be eventually fixed by the chip vendor. Hence <3$ for an IoT device is indeed compelling, however unfortunately you end up paying with spending several times more time to accomplish the same basic results.

We may eventually consider creating a list of the low-level tool issues and launching a crowdfunding campaign to fix them in the free tools, but it is hard to say how successful this would turn out.

We hope this explains it and sorry for the inconvenience caused by this.

and

As we don't have any insight in the closed-source parts of the ESP8266 libraries, unfortunately we cannot offer much help here. Please consider asking on the Espressif forums

despite all this - I still find the ESP8266 quite appealing. Hard to beat the price, size, and capabilities. I've been using the VisualMicro add-in for VisualStudio - really quite awesome, although different as not a JTAG/hardware debugger like VisualGDB.

[JohnS]

Thanks for that info.  Maybe will help others...

John