[gojimmypi]

Hello & thanks for your reply. I’m not entirely convinced that all of the blame is on the ESP8266 (although ya, it is hard to argue with issues like “undocumented”, eh?)

I created a video on my ESP8266 debugging experience (based on the Olimex per your suggestion. I’ve not yet had a chance to target the NodeMCU) Here you’ll see what I consider “unexpected” operations when single stepping.

https://youtu.be/9Hid7ixEigM

You’ll see in the video, VisualGDB seems to do best when “running to breakpoint”, and not so much when single-stepping. This leads me to wonder if when single-stepping, VisualGDB could (in theory) programmatically place similar, pseudo-breakpoints?

If nothing else, perhaps you should tell users about that. So many times when I’d see the “Frame not in module” error – I thought: “game over, not working”.

And ya – I know there are more robust target platforms out there, however <$3 for a complete IoT device is pretty compelling. 🙂

<edit>fwiw: Here’s a detailed experience I wrote on the Olimex forum, when I thought it might by a problem with my new JTAG hardware: https://www.olimex.com/forum/index.php?topic=5676.msg23470#msg23470 </edit>

• This reply was modified 7 years, 9 months ago by gojimmypi. Reason: added link to more detailed description of issues left on Olimex forum :)

[gojimmypi]

Just closing up this issue for anyone else that comes looking: Don’t even bother trying to get the Altera Bus Blaster programming an ESP8266 from VisualGDB. It won’t work. For one – there’s no reset control line.

I did end up buying an Olimex ARM-USB-OCD-H from Mouser Electronics for about $60. Debugging is not very intuitive. The result of single-stepping is a bit unexpected and even unpredictable. It works, you just need to know the tricks. I have a video that demonstrates this:  https://youtu.be/9Hid7ixEigM

There’s a longer thread over on the Olimex forum, as I originally thought there was a problem with their device (but not):  https://www.olimex.com/forum/index.php?topic=5676

Bottom line is many errors can (apparently) be ignored; Debugging may be actually working, even though it looks like it is not.

 

 

 

[gojimmypi]

Hello.

Well I ordered an Olimex ARM-USB-OCD-H to try instead of the Segger, and while at it I also took your advice and ordered an Olimex ESP8266-EVB. I’ve spent all day trying to get the JTAG debugging working, with no success. I am able to get GDB debugging working via the serial pins, but not JTAG.

VisualGDB insists on installing only its driver when pressing the “Test Settings” button. However I get this result:

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
Info : TAP esp8266.cpu does not have IDCODE
Warn : Warning: Target not halted, breakpoint/watchpoint state may be unpredictable.
Info : accepting ‘telnet’ connection on tcp/4444
shutdown command invoked
Info : dropped ‘telnet’ connection

Although VisualGDB pops up a dialog box saying that “your settings appear to be valid”… well, given the error, no surprise that I am unable to program or debug via JTAG.

I’ve double, triple, quadruple checked my pin-by-pin connections:

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

and following this tutorial:

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

If I ignore the message and try to debug anyhow, I get this result:

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_dra
in connect_deassert_srst
adapter speed: 1000 kHz
stop_wdt
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : clock speed 1000 kHz
Info : TAP esp8266.cpu does not have IDCODE
Warn : Warning: Target not halted, breakpoint/watchpoint state may
be unpredictable.
Info : accepting ‘gdb’ connection on tcp/3333
undefined debug reason 7 – target needs reset
Warn : target not halted
Info : TAP esp8266.cpu does not have IDCODE
Warn : xtensa_deassert_reset: ‘reset halt’ is not supported for Xte
nsa. Have halted some time after resetting (not the same thing!)
target state: halted
Info : halted: PC: 0x40244a26
Info : debug cause: 0x20
Error: xtensa_step: Timed out waiting for target to finish stepping
.
Warn : target esp8266.cpu is not halted
Info : halted: PC: 0x40244a05
Info : debug cause: 0x20
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
Info : halted: PC: 0x40100004
Info : debug cause: 0x2
Info : halted: PC: 0x4010017d
Info : debug cause: 0x10

It actually does stop on my breakpoint!  But it is not actually debugging C code, as I drop into the “Frame not in module” message. Sometimes thought, it seems that I can actually step though the assembly language. And although that might be interesting at other times – I’m trying to debug C code.

If I try to force any other drivers with zadig or UsbDriverTool – VisualGDB wants to force its own version when selecting a programmer.

I’ve burned through another week of my eval, and I’d really like this to work… any suggestions would be greatly appreciated.

Thanks

 

 

 

 

 

 

[gojimmypi]

since you bring it up, I’ll add my voice that this forum, although responsive from support & containing great information – has… well… “things to be desired” from a usability perspective 😉

try using google “site” selector, for instance search this site for instances of esp8266:

esp8266  site:sysprogs.com

[gojimmypi]

that’s a cool feature! the link is to a Linux debug, however I am trying to quick debug an embedded ESP8266 app using a Segger J-Link. Is that possible?

I’m really close, as shown in the pics for setup & test:

https://twitter.com/gojimmypi/status/822808553895247873

However when debugging, I end up with a “Frame not in module, The current stack frame was not found in a loaded module”.  Is any additional software needed for ESP8266 quick debugging?

 

 

[gojimmypi]

thanks for your reply. What about the issue of  <span style=”font-family: Thread-0000079c-Id-00000082;”>C:\SysGCC\esp8266</span>  vs <span style=”font-family: Thread-0000079c-Id-00000082;”>C:\SysGCC\xtensa-lx 106-elf ? </span>How can I determine if I’m using the correct toolchain?  (I don’t have the xtensa-lx 106-elf  in the dropdown, even after manually installing the esp8266-gcc5.2.0-r9.exe toolchain download)

Unfortunately I don’t have an Olimex ESP8266-EVB board – however I’ve used the references for that ESP8266 to connect to my NodeMCU equivalent pins.  See:

https://twitter.com/gojimmypi/status/822571682544185344

btw – given that warning  “if you are using OpenOCD instead of xt-ocd, connect the reset signal to JTAG20 pin 3, not pin 15” – please note I am using pin 3.

thanks again for your help 🙂

[gojimmypi]

Upon disabling Norton, I was able to install esp8266-gcc5.2.0-r9.exe from

http://gnutoolchains.com/esp8266/

(I had previously also installed esp8266-gcc5.2.0-r8.exe )

I left the defaults, and it appears to have installed to C:\SysGCC\ESP8266 as shown here:

https://twitter.com/gojimmypi/status/820986248969981953

although there’s a C:\SysGCC\esp8266\xtensa-lx106-elf directory. (but not C:\SysGCC\xtensa-lx106-elf as shown in the tutorial)

I’m following the tutorial for OpenOCD on the ESP8266 here:

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

And I have a Segger J-Link that I am trying to use, that seems mostly happy (see second pic with pins used):

https://twitter.com/gojimmypi/status/822541791027200002

However when attempting to debug, I see this in the OpenOCD Window:

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
Info : J-Link V10 compiled Jan  9 2017 17:48:51
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 101000
Info : J-Link hw type J-Link
Info : J-Link max mem block 22664
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.335 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1
Info : J-Link JTAG Interface ready
Info : clock speed 1000 kHz
Info : TAP esp8266.cpu does not have IDCODE
Info : halted: PC: 0x40003b53
Info : debug cause: 0x20
Info : accepting ‘gdb’ connection on tcp/3333
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway…
Error: esp8266.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : xtensa_deassert_reset: ‘reset halt’ is not supported for Xtensa. Have halted some time after resetting (not the same thin
g!)
target state: halted
Info : halted: PC: 0x4000dd38
Info : debug cause: 0x20
Info : halted: PC: 0x4000dd3b
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
Info : halted: PC: 0x40100004
Info : debug cause: 0x2

And this in this GDB Session Window:

Your VisualGDB trial expires in 23 days!
C:\SysGCC\esp8266\bin\xtensa-lx106-elf-gdb.exe –interpreter mi C:\workspace\Segger3\VisualGDB\Debug\Segger3
Warning: could not set a breakpoint on main. ‘Step into new instance’ will not work.
Loaded image in 17142 ms
Cannot resolve the address of _estack. Skipping stack pointer validity check.

And sure enough, I am unable to stop at breakpoints.

It appears the main problem is that I still am not using the xtensa-lx toolchain, eh?

Any suggestions?

Thanks.

[gojimmypi]

Hi.

Thanks for your reply. I have rebooted and still no difference.

I have been unable to upload a picture on the forum here. No errors, but no actual picture appears at end of process – so I tweeted a pic of the toolchains I see here:

https://twitter.com/gojimmypi/status/820986248969981953

I’m using Visual Studio 2015 Version 14.0.25431.01 Update 3 with VisualGDB 5.2

Upon trying to re-run the installation, Norton Anti-virus intervened, claimed it was a virus, and deleted my download file (not sure why it would not have done that the first time around – obviously I was able to download it, and I’m fairly sure it ran successfully without incident).

http://sysprogs.com/files/gnutoolchains/esp8266/esp8266-gcc5.2.0-r9.exe

I tried to download again, and this time Norton immediately deletes the file.

I did not have a problem with the similar process for the MSP430 a few days ago. I still have that file, and Norton Insight says that less than 5 users have used the file (sometimes Norton will think something is bad if there’s no user history). However this MSP430 file is still there, Norton is happy with it, and I was able to successfully install the toolchain to find my specific MSP430FR6989

It would not be the first time that Norton gives a false positive. But before I force the file onto my system, can you confirm the ESP8266 toolchain here is indeed virus free?

Thanks

[gojimmypi]

Thanks for your reply. I’m looking at the ESP8266 tutorial here:

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

I was about to order an Olimex ARM-USB-OCD-H per your suggestion, however:

The end of Step 1 says:

Note that we use the Olimex USB-OCD-H as a USB-to-COM adapter only as the Xtensa JTAG software does not support it (supported devices are listed below).

Which sounds like the OCD-H is *not* being used as JTAG, rather a simple USB-to-TTL (Rx/Tx) port?

Further down in Step 7 there’s a note:

VisualGDB supports 3 debug methods for ESP8266 devices:

• A special OpenOCD port that supports all JTAG programmers supported by the original OpenOCD
• Xtensa OCD Daemon (xt-ocd) that supports ML605, Flyswatter 1/2/3, Jtagkey 2, Olimex tiny-h, Segger J-link, ByteTools Catapult, RVI JTAG and Macraigor probes
• GDB stub from Espressif that does not requre a separate JTAG connection

Note it specifies a *different* Olimex device, the  “Olimex tiny-h” – which is listed as a USB JTAG device here: https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY-H/

The ARM-USB-OCD-H is listed as a “3-IN-1 fast USB ARM JTAG, USB-to-RS232 virtual port and power supply 5VDC device” here:

https://www.olimex.com/Products/ARM/JTAG/ARM-USB-OCD-H/

and both of the products say “supported by OpenOCD arm debugger”

Am I misreading the tutorial? Could you please confirm the recommendation for ARM-USB-OCD-H despite what Steps 1 & 7 say? (I think they may actually be essentially the same device; the more expensive one including the Tx/Rx & power, eh?)

As I have no experience with these Olimex devices, any suggestions or clarifications will be greatly appreciated before I place an order. 🙂

Thanks

 

[gojimmypi]

actually, please disregard the question on “Cannot resolve the address of _estack” as apparently is can be ignored! I have it working with my MSP430!

https://sysprogs.com/w/forums/topic/problem-debugging-esp8266/

I’ll start a new topic regarding Bus Pirate and USB Blaster

[gojimmypi]

thanks a lot for prompt reply!

Indeed the x6989 is in that toolchain and it compiles successfully in Visual Studio 2015 Version 14.0.25431.01 Update 3 with VisualGDB 5.2

However, I am unable to single step the “blink” example:

1>—— Build started: Project: GDB-8, Configuration: Debug VisualGDB ——
1>  LEDBlink.cpp
1>  Linking ../VisualGDB/Debug/GDB-8…
1>  ——————- Memory utilization report ——————-
1>  Used FLASH: 578 bytes out of 46KB (1%)
1>  Used RAM: 24 bytes out of 2048 bytes (1%)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Your VisualGDB trial expires in 30 days!
C:\SysGCC\msp430-elf\bin\msp430-elf-gdb.exe –interpreter mi C:\workspace\GDB-8\VisualGDB\Debug\GDB-8
Cannot resolve the address of _estack. Skipping stack pointer validity check.

Any suggestions as to what I might be doing wrong?

Really my goal is to program the ESP8266/ESP32 however I don’t currently have any of the mainstream JTAG tools (I’ve tried my Altera USB Blaster and Bus Pirate without success using OpenOCD)…. so I thought this MSP430 might be easier to get acquainted with the VisualGDB software until I can get a Segger J-Link. (that’s a good JTAG interface for the ESP family, right?)

Thanks a lot 🙂

 

 

 

[Author]

Posts