Hi,
I’m new to PlatformIO and ESP Processors, but doing embedded software on various platforms for many years.
However, this drives me crazy
I started with a simple LED blinker, uploaded it via USB, works fine.
I learned, that debugging is not possible via USB - only JTAG. I also found that I can use the FT232H.
Fine, I still have a Digilent HS3 for my FPGA-Boards, which is pretty much the same.
I checked the USB-IDs with FT_Prog - fine. The plain FTDI driver is installed.
Starting a debug session just stops after the build, no error message.
I found that I can set “debug_tool = Grbage4711” and it would do the same.
Then I added the upload-protocol and tried upload. I got the warning “Warning! Unknown upload protocol esp-prog”.
Now I’m really frustrated. I don’t find any troubleshooting and the tool doesn’t tell me what’s wrong
I forked into https://github.com/maxgerhardt/sysprogs-esp8266-openocd since there were some compiler errors for me. Now I do have that OpenOCD version compiled. I uploaded (regularly) this sketch to my NodeMCUv2 as is recommended by that blog post:
It actually manages to get a connection to the chip!
Open On-Chip Debugger 0.10.0+dev-g63d9b121 (2023-11-05-15:10)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
stop_wdt
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : TAP esp8266.cpu does not have valid IDCODE (idcode=0xfffffffe)
Info : halted: PC: 0x40000f68
Info : debug cause: 0x20
Info : Listening on port 3333 for gdb connections
The reset problem was due to incorrect OpenOCD adapter configurations and I was able to resolve it. It can now reset the chip via OpenOCD. The problem is however that there is no “reset but don’t start running code”. There is only “reset and try to halt execution ASAP afterwards”. But at that point, init code and setup() has already run, so setup() can’t be initial breakpoint anymore, only loop, after it has done a few iterations… Not yet sure how to handle this well. One way good to delay() for debugger connection before in setup() in the core for a debugger connection, then this works.
In any case, this is not production ready yet and I doubt that’ll change in the short term. Even if I get it running, getting it all stable and accepted back into mainline will take its time.
Thank you @maxgerhardt for your quick and detailed reply.
I’ll try your suggestions when I have time.
I was hoping to put my efforts in my task and not in the toolchain.
Right now, I help myself with UART monitor and logic analyzer.
I have also problems getting reliable hardware docs.
I think, I’ll focus on my other projects and keep this one as
“weekend hobby”.