Openocd jtag driver problem

[freeck]

Hi,

I tried to use my jtag device , but ran into trouble.  Although visualgbd recognizes the jtag device, but I got this error message:

Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED

Error: no device found

Error: unable to open ftdi device with vid 15ba, pid 002a, description ‘Olimex OpenOCD JTAG ARM-USB-TINY-H’ and serial ‘*’

This suggest that the libusb is not installed, not? But I used utility “usb driver tools” to install them….!?

 

[support]

Hi,

If this is a reprogrammed ARM-USB-OCD-H or another device, please use the ST-Util to restore the original VID/PID and specify the OpenOCD script accordingly. Please also ensure that you have a WinUSB-based driver installed. You can install it manually using USBDriverTool.

[freeck]

The driver installation problem seems to be solved. I used the DriverTool , but before installing the driver you have to disable Driver signature verification, and reboot !!! If you don’t , Win10 generates an error during driver installation.

I have set a breakpoint in function <span style=”color: #800000; font-family: Consolas; font-size: small;”>user_init</span><span style=”font-family: Consolas; font-size: small;”>() </span>at statement <span style=”color: #800000; font-family: Consolas; font-size: small;”>gpio_init</span><span style=”font-family: Consolas; font-size: small;”>();</span>

and downloaded the LEDblink-example to the target. But the setpoint is never reached….

<span style=”text-decoration: underline;”>Output Openocd window: </span>

 Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED  (strange error message…)
Info : clock speed 1000 kHz
Info : TAP esp8266.cpu does not have IDCODE
Info : halted: PC: 0x40002ef4
Info : debug cause: 0x20
Info : accepting ‘gdb’ connection on tcp/3333
Info : TAP esp8266.cpu does not have IDCODE
Warn : xtensa_poll: DOSR has set InOCDMode without the Exception flag. Unexpected. DOSR=0x04
target state: halted
Info : halted: PC: 0x40002ef4
Info : debug cause: 0x20
Warn : xtensa_deassert_reset: ‘reset halt’ is not supported for Xtensa. Have halted some time after resetting (no
t the same thing!)
Info : halted: PC: 0x40002eee
Info : debug cause: 0x1
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Info : halted: PC: 0x4010013c
Info : debug cause: 0x8
Interrupt suppression during single-stepping is now enabled
Watchdog feeding during stops is now enabled

• This reply was modified 9 years ago by freeck.

[support]

Hi,

What exactly is happening to the device? Is the LED blinking? Did the FLASH programming progress window appear? What is the contents of the GDB Session window (if you enable “All commands” view)?

Does changing reset mode in VisualGDB Project Properties help? Have you tried connecting the reset to pin 3 on your JTAG20 as described in the tutorial?

[freeck]

<b>Led-blink example (ram):</b>

I observe that using jtag- or gdbstub-debugging using RAM-only works flawlessly. So no driver and connection issues. Breakpoint and single stepping function works OK. LED blinks.

<b>http-server example or ledblink (flash versions):</b>

Using gdb-stub downloading went OK, I could set a breakpoint and continue execution. I saw the wifi station in the air or the LED blink.  So the application seems to run. Strangly enough after a reset the application is not running, or not flashed, or not started…..(part of the problem?)

Using the jtag device: FLASH-downloading seems to go OK , no error messages in the gdb-window. However the breakpoint is never reached, and I observe no wifi-activity, nor the LED blink. So obviously the programmes have not started.

Changing reset mode and dis- and connecting the reset pin had no effect.

 

[support]

Hi,

If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect. Perhaps this is causing the behavior you are describing. This can be easily checked by pressing the “Break in” button in Visual Studio and examining the call stack.

You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

[freeck]

If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect.

You mean that a background process has already started before calling gbdstub_init()? If not: this does not explain why I could not reach a breakpoint in user_init()….and: In case I define a project example without gdbstub the application also does not start…..

I response to your questions:

-Using break all ( not “in”): The call stack shows some assembly instructions , no names of functions.

I observe a break at address: 0x40002eee

 

– Setting GDBSTUB_BREAK_ON_INIT=0 had no effect

– Commenting out gdb_init() had no effect.

 

 

[support]

Hi,

OK, then the problem must be elsewhere. Please double-check your FLASH type setting (dio/qio/etc) in VisualGDB Project Properties.

Please also try manually programming the <project>-0x40000.bin and <project>-0x00000.bin files from the Debug directory using the bootloader and esptool.py.

If the LED blinks in that case, something goes wrong with programming the FLASH over JTAG. If the LED does not blink (but blinks when you are using the GDB stub), something about the images is corrupt and the next step would be to compare the images produced when using the OpenOCD debug method with the images produced from the same ELF file when using the gdb stub.

[freeck]

I think you were right stating:

If your program still contains the gdb stub, the stub will stop at the beginning of the program and wait for gdb to connect.

When I download the code using the esptool the code is also not running….But a gdb-stub status message appears via the serial interface! So in case you use gdbstub is will indeed hold up the application. So the question remains how to build an image without the gdbstub-stuff?  You stated: You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

I hope I did put the define on the right place in the makefile, but I observe that the gdb-stuf is always included in the image..also in case I build a non-gbdstub example application.
It remains a mystery to me why the jtag-debugging is also held up by gdbstub…

• This reply was modified 9 years ago by freeck.
• This reply was modified 9 years ago by freeck.
• This reply was modified 9 years ago by freeck.
• This reply was modified 9 years ago by freeck.

[support]

Hi,

It’s hard to guess what exactly went wrong, but reasons could vary from files simply not rebuilding to some typos in the preprocessor macros.

We would recommend something like this:

1. Add a static variable pre-initialized to a certain string (e.g. “test123”), use this variable from user_init() so that it gets referenced. At the same time comment out the call to gdbstub initialization.
2. Does the binary image contain your string (test123)? If no, it did not get rebuilt properly. Note that the ESP8266 .bin images are only rebuilt when you start debugging with VisualGDB, not when you build the project.
3. Do you still get the gdb stub message? If yes, some other code is calling it. Perhaps user_init() is defined in 2 different places and one takes precedence over the other one?

The JTAG debugging would be held by gdbstub because gdbstub essentially installs a handler to some debug-related interrupts, then triggers an interrupt and that interrupt handler waits for a reply via the COM port. The JTAG debugger does not prevent interrupts from being handled, i.e. the stub will still catch it and start waiting for gdb to attach. Once gdb attaches, however, you can still use the JTAG debugger to see what’s going on inside the stub and inside your code.

[freeck]

Hi there,

PROBLEM SOLVED

You can disable this by defining GDBSTUB_BREAK_ON_INIT=0 in VisualGDB Project Properties -> Makefile Settings, but this will prevent you from debugging your program, from the very beginning using the stub, as the program will quickly advance beyond user_init() before VisualGDB manages to connect to it.

I modified the preprocessor-macro in file esp8266.mak itself, only then the gdb-stub break_on is disabled. So the preprocessor-macro in VisualGDB “Project Property->MakefileSettings” were not propagated to esp8266.mak !

• This reply was modified 9 years ago by freeck.

[support]

Hi,

The settings from VisualGDB Project Properties are saved in debug.mak/release.mak, while esp8266.mak contains settings that are common for all configurations.

Please double-check the settings in debug.mak and see if they are actually included in compilation command line.

[freeck]

Please double-check the settings in debug.mak and see if they are actually included in compilation command line.

Yes they are, but: I observe that the macro settings of esp8266.mak overrule the settings of debug.mak. Changing GDBSTUB_BREAK_ON_INIT in debug.mak has no effect. I think macro GDBSTUB_BREAK_ON_INIT=1 should not be included in esp8266.mak for any new project….but in debug.mak, not?

• This reply was modified 9 years ago by freeck.

[support]

Hi,

The settings should normally be merged. Can you attach an archive of a sample project where the settings are not propagated properly?

[Author]

Posts