[gojimmypi]

Aha! Thanks for that information. I did not know you folks even had such a tool. Apparently it is a separate download / install from the VisualGDB add-in:

http://visualgdb.com/UsbDriverTool/

As a feature request, perhaps you could put that information in the “Try installing it now?” dialog box. Having instructions on how to then roll back after the drivers are changed would be really helpful. (and in my case, would have saved hours of frustration trying to get the Segger utilities working again)

Additionally, just for completeness of this topic and the benefit of other that may come looking: the folks at Segger pointed out to me that there’s yet another cool Sysprogs Tutorial that uses the Segger GDB Server rather than needing to change the OpenOCD USB drivers:

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

This is not just an STM32 device tutorial… as it also shows using the J-Link JTAG as a debug method rather than OpenOCD (see steps 9 and 10) thus no need to change the drivers for OpenOCD.

I had instead used this tutorial when first taking my J-Link for a test drive:

https://visualgdb.com/tutorials/arm/st-link/

It is unfortunate that so much really great information is somewhat “lost” in the tutorials. I would have never thought to look at that STM32 tutorial for alternate debug methods. Are there any plans for a wiki or other “all you ever wanted to know about VisualGDB” documentation? (or where: perhaps I’ve simply not found it)

In any case I added a supplementatory blog page on this topic:

http://gojimmypi.blogspot.com/2017/03/more-on-segger-j-link-and-visualgdb.html

Hopefully that might help others that encounter a similar problem. 🙂

Thanks again for your reply.

 

 

 

[gojimmypi]

oops, not the STM32 ST-Link Utility (that’s of course for the ST-Link/V2 debugger).  The tool I meant to say is the Segger J-Link Configuration tool for updating firmware on the J-Link

(this pesky forum – sometimes I can edit prior posts and sometimes not)

[gojimmypi]

If not a wiring problem – I wonder if perhaps the problem may be old firmware on the J-Link. See the line:

Info : J-Link ARM V8 compiled Nov 28 2014

When I first installed my J-Link, I ran the Segger STM32 ST-Link Utility and it wanted to update my firmware before even trying to use it. Here’s the result of my selftest:

C:\SysGCC\esp32\esp32-bsp\OpenOCD\bin\openocd.exe -f interface/jlink.cfg -f target/esp32.cfg -c “adapter_khz 3000”
Open On-Chip Debugger 0.9.0 (2016-11-21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport “jtag”. To override use ‘transport select <transport>’.
adapter speed: 3000 kHz
Info : No device selected, using first device.
Info : J-Link V10 compiled Jan  9 2017 17:48:51
Info : Hardware version: 10.10
Info : VTarget = 3.348 V
Info : clock speed 3000 kHz
Info : JTAG tap: esp32.cpu0 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : JTAG tap: esp32.cpu1 tap/device found: 0x120034e5 (mfg: 0x272 (Tensilica), part: 0x2003, ver: 0x1)
Info : esp32.cpu0: Target halted, pc=0x400D4492
Error: The ‘mww’ command must be used after ‘init’.
in procedure ‘init’
in procedure ‘ocd_bouncer’
in procedure ‘flash’
in procedure ‘ocd_bouncer’

Info : esp32.cpu1: Target halted, pc=0x400D0BB0
Info : accepting ‘telnet’ connection on tcp/4444
shutdown command invoked
Info : dropped ‘telnet’ connection

btw – coincidentally I’ve been working on the ESP32 today. It is shockingly easier to JTAG than the ESP8266.  I created my own pinout diagram and posted all my notes (including ESP32 hookup) here:

http://gojimmypi.blogspot.com/2017/03/jtag-debugging-for-esp32.html

Let’s see if this tweet shows up as a hookup pic:

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

Hope this helps…

 

[gojimmypi]

Yes, that worked! Thank you.  I completely uninstalled VisualGDB, rebooted and installed fresh; VisualGDB now operational in both Visual Studio 2015 and 2017.  🙂

 

 

[gojimmypi]

We will consider making a crowdfunding campaign to fix the common annoyances of the open-source ESP8266 debug tools (gdb/OpenOCD)

Sign me up!!! 🙂

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

 

[gojimmypi]

Yes, I’ve tried using the bootloader mode when attempting to program via JTAG, even though there was no prompt as with the GDB stub method. I’ve still not yet been successful. Given the nature of JTAG, I wasn’t really sure if this was needed or not.

fwiw – I recently tried VisualGDB with an STM32 device (specifically the STM32F103c8 found in the Smart V2):

http://wiki.stm32duino.com/index.php?title=STM32_Smart_V2.0

my setup / result pics here:

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

wow! It was amazingly simple to setup and debug! I’ve spent a huge amount of time trying to get this to work with the ESP8266… and just minutes with the STM32, following this OpenOCD tutorial (but with Segger J-Link, instead):

https://visualgdb.com/tutorials/arm/st-link/

I really hope you folks can get the ESP8266 (and ESP32) information you need from Espressif folks to make ESP8266 debugging as easy and robust as you’ve done with STM32.  (hard to beat a full SOC IoT device with WiFi for as little as 3 bucks).

So between this success, and the really impressive remote debugging that I was able to get working from Visual Studio to Raspberry Pi… well, VisualGDB is awesome!  🙂

[gojimmypi]

fwiw – I have been able to successfully send os_printf(“message”) values to the serial port from the ESP8266 when programmed with VisualGDB.

Reminder that if not otherwise initialized, the default port speed is 74880 (8N1 / no flow control); this can be very useful when debugging as there are system messages always printed at powerup / reset time.

I suggest also the very first thing to send is a message with the exact version you are testing, as I have had occasion when it would appear that code was sent to device, but not.

 

[gojimmypi]

Hello.

I’m glad the github project I uploaded was helpful in finding & fixing that problem.

Regarding your  ESP8266 package; I tried adding that OpenOCDPackage.dll reference, however I still get a (different) compile error. See comment:

https://github.com/sysprogs/BSPTools/issues/3

As for the ESP-12… well, I’ve successfully programmed it with the GDB method! I am able to set breakpoints both in init section, as well as web server section that gets triggered when I connect to the web page served up by the ESP-12. The weird thing is that when I stop debugging, the ESP-12 code is no longer running (or at least the WiFi hot spot is not seen), even after power cycle.

I have GPIO0 and GPIO2 tied high and GPIO15 tied low with 470 ohm resistors.

When I power cycle the ESP-12, I see this message from the serial port, just once with no more data:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x3ffe8000, len 940, room 16
tail 12
chksum 0xc3
ho 0 tail 12 room 4
load 0x3ffe83b0, len 936, room 12
tail 12
chksum 0xfc
ho 0 tail 12 room 4
load 0x40100000, len 30536, room 12
tail 12
chksum 0xe9
csum 0xe9
OS SDK ver: 1.5.0-dev(950076a) compiled @ Nov  4 2016 19:29:32
phy ver: 1055, pp ver: 10.7

rf cal sector: 251
tcpip_task_hdl : 3fff0620, prio:10,stack:512
idle_task_hdl : 3fff06c0,prio:0, stack:384
tim_task_hdl : 3fff2c78, prio:2,stack:512
$T05#b9

Now, if the GDB debugging session properly uploaded the code… it should run, even when not debugging, no? I’m not familiar with the inner workings of this type of debugging, so I’m not sure if this is expected behavior.

Thanks again for your assistance.

[gojimmypi]

I have a plain ESP12, with no accessories, and I will test JTAG programming with that – instead of trace cutting on the NodeMCU.  🙂

In the meantime – I was able to reproduce the error mentioned above – but of course not when desired! I tried to record a video a bunch of times, but in the end no error. But now – I have a project with the exception error! Curiously, it was at new project time, and I did not at all expect it. I was simply setting up a new GDB session for the bare ESP12.

Although I cannot tell you what sort of steps I did differently – the project itself seems to have the problem saved with it. So I uploaded the whole project to GitHub, if you’d like to take a peek and see if you see the same problem. Simply open the project,  click “Debug – Program and Start without Debugging”. It does not matter if you have an ESP8266 connected or not. Immediately after attempting the upload the exception occurs.

https://github.com/gojimmypi/E12-GDB2

see also: https://github.com/gojimmypi/E12-GDB2/blob/master/Error.PNG

btw – thanks for the tip on your ESP8266DebugPackage. It looks really interesting, but I was unable to compile it. I opened a GitHub issue (ho! that you seem to have already closed and answered – thank you!). But for reference in this thread for anyone else that may be interested:

https://github.com/sysprogs/BSPTools/issues/3

You can get the OpenOCDPackage.dll by installing OpenOCD via Tools->VisualGDB Package Manager. Then simply add a reference to %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\OpenOCDPackage.dll and you should be able to build the ESPImageTool and the related libraries.

Thanks again for all the help with the ESP8266! 🙂

 

[gojimmypi]

The “Error: JTAG scan chain interrogation failed: all zeroes” error almost 100% indicates a wiring problems (that also includes power and reset issues).

I’d like to add that I’ve recently found that simply power-cycling the ESP8266 and JTAG programmer has resolved my “all zeros” problem as well.

But I agree that adequate power is important, as well as understanding the reset line (e.g note the NodeMCU can control the reset line via serial port RTS/DTR lines)

 

[gojimmypi]

Hi.

 

Sorry I did not make that more clear. Using the command-line esptool.py – I am able to program the NodeMCU without having to hold down the Flash button. However when using VisualGDB, I always need to hold down the flash button. And not just “hold down during power cycle”… but I usually need to even hold it down until VisualGDB starts transferring code.

Thus my “feature suggestion” is to make the VisualGDB app work more like the esptool.py in not having to hold down the flash button to program it.

As this ablity may vary between different “flavors” of ESP8266… perhaps a related feature suggestion is to have a dropdown with pre-selected parameters for some well-known ESP8288 hardware, plus a “Generic” option for everything else?

[gojimmypi]

Hi again.

Ok, 4th reply here. (I would have appended my prior posts, but this forum app does not seem to always allow editing?)

So as to the original topic: JTAG debugging of the NodeMCU. No luck. Despite the success of VisualGDB and the GDB debugging via UART, the JTAG method still eludes me.

It will go through all the motions, even at times apparently stopping at the breakpoint. However I can’t single step afterward, and in fact the code is either not running, or not on the chip – even after complete power cycle. No exception errors are spewing at 74880, but there’s also no WiFi server running as compared to uploading with GDB.

Again, although the JTAG test is successful when first setting up the project, I see errors at upload time:

Info : TAP esp8266.cpu does not have IDCODE
Warn : Warning: Target not halted, breakpoint/watchpoin
t state may be unpredictable.
Info : accepting ‘gdb’ connection on tcp/3333
undefined debug reason 7 – target needs reset
Warn : target not halted
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 suppo
rted for Xtensa. Have halted some time after resetting
(not the same thing!)

I am completely open to other ideas.  🙂

[gojimmypi]

Hi Kabron –

I am in a similar situation! Although the topic is JTAG, part of the exercise was to revert to Serial GDB debugging on my Node MCU ESP8266:

https://sysprogs.com/w/forums/topic/jtag-programming-the-nodemcu-esp8266/#post-10466

In short, check the debug settings at *project creation time*… and make sure they match your board’s actually hardware.

I really think there’s a problem when changing the parameters once a project is created.

Also – note VisualGDB creates *two* binary files – whereas the Arduino core creates only one. Thus the memory size is even more important to have correct (and to distinguish whether the units are bits or bytes)

Hope this helps…. 🙂

[gojimmypi]

ok, success! There really does appear to be a problem with changing *existing* project debug parameters (VisualGDB gets really cranky, see prior posts), but when creating a NEW project, writing to the NodeMCU with Mode=dio, size=32m (bits) allows successful single-step GDB debugging!

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

[gojimmypi]

Just to confirm, the output of the FC command shows first the byte from one file, then the difference in the other file.

00000002: 02 00
00000003: 40 20

Thus there is no “02 00” nor “40 20” (the 02 is in the file written, the 00 is in the other file read)

The first 8 bytes of each file:

File Written: E9 01 02 40 9C F2 10 40   = DIO 32m; I write DIO at 4M = (4M bytes x8=32m bits)
File Read:    E9 01 00 20 9C F2 10 40   = QIO 8m; (does it get changed to QIO 1Mx8=8m?)

 

 

• This reply was modified 8 years, 8 months ago by gojimmypi.

[Author]

Posts