using rpi as ftag debugger for esp32

Sysprogs forums Forums VisualGDB using rpi as ftag debugger for esp32

This topic contains 4 replies, has 2 voices, and was last updated by  TracesOfNut 1 week, 6 days ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #20875

    TracesOfNut
    Participant

    Hi,

    I am trying to debug an esp32 with VisualGDB.

    I don’t have a suitable usb debugger, but have a raspberry pi.   I found some posts about using a raspberry pi as a jtag programming dongle.  I connected up an esp32 to it and then built openocd (on the rpi ) from source (with –enable-sysfsgpio). When I run openocd on the rpi identifies the esp32 and waits for a connection.

    I am not sure how to setup VisualGDB for this though.  The closest I got was using Full-custom mode and entering the gdb target selection command ( target remote 192.168.1.13:333 ). When I try to debug, openocd on the rpi shows the connection , but VisualGDB  gets stuck trying to run GDB commands like -gdb-version, -list-features etc (reports as undefined commands i think). If I cancel a lot of commands, the Hard Registers tab is filled out with a lot of registers.  So it looks like the two are talking ok, but VisualGDB tries to run a command every couple of seconds and hangs.

    I also tried selecting a few openocd jtag programmers, but got  the message that visualgdb’s gdb didn’t support the them (do i have to rebuild the windows sysgcc version).

    Am I on the right track?  I am not sure whether VisualGDB should be using openocd locally to connect to the openocd running on the rpi, or running gdb locally with an ip address to connect to. Or should a buy a segger j-link?

    Any help is greatly appreciated.

    regards

    Justin.

    #20876

    support
    Keymaster

    Hi,

    The easiest way would be to use the “custom gdb stub mode” instead of the “full-custom” one. VisualGDB would then automatically configure the GDB arguments (the problem you are describing looks like a missing “–interpreter mi” argument to gdb).

    Another option would be replace the OpenOCD binary in the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\…openocd\bin with the one you built and manually pick the Rasberry Pi interface file.

    It is strange that VisualGDB did not support some JTAG programmers; our OpenOCD build uses default build settings, so all programmers that are normally supported, should work. Feel free to share more details about this and we can help you figure it out.

    Also Segger J-Link is recommended only if you are looking for 100% out-of-the-box experience for a wide variety of devices. If you are OK playing around with OpenOCD scripts (or are only using popular devices like STM32), getting an inexpensive Olimex probe should do the job as it works very well with OpenOCD.

    #20878

    TracesOfNut
    Participant

    This morning, I decided to buy a proper debugger, but the raspberry pi is still something I would like solve eventually.

    With custom gdb mode, i couldn’t find where to enter in the target remote command.  I tried the -interpreter mi argument though with both options without success.

    With the gdb devices, this ( see below )  is what gets reported under windows when I tried the sysfsgpio-raspberrypi interface (The command is basically the same as the one I run on the raspberry pi).  I noticed when I build openocd, I have to use the –enable_sysfsgpio for make as it is not preselected.  There was another device in the VisualGDB list, but I was trying random ones to see if any expected a network address, and can’t remember which one.

    With VisualGDB, I am assuming that the openocd running on the PI is basically acting as a GDB server.  I can understand why that one needs the sysfsgpio-raspberrypi.cfg interface configuration in order to communicate through the gpio pins, but why does the openocd running under VisualGDB (windows 10) need to know about it?

    Justin.

    c:\SysGCC\esp32\esp32-bsp\OpenOCD\bin\openocd.exe -c “gdb_port 57902” -c “telnet_port 57903” -f interface/sysfsgpio-raspberrypi.cfg -f target/esp32.cfg -c “adapter_khz 3000” -c “echo VisualGDB_OpenOCD_Ready”
    Open On-Chip Debugger 0.9.0 (2017-08-05)
    Licensed under GNU GPL v2
    For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
    Error: The specified debug interface was not found (sysfsgpio)
    The following debug interfaces are available:
    1: ft2232
    2: ftdi
    3: usb_blaster
    4: usbprog
    5: jlink
    6: vsllink
    7: rlink
    8: ulink
    9: arm-jtag-ew
    10: hla
    11: osbdm
    12: opendous
    13: aice
    14: cmsis-dap

     

    #20887

    support
    Keymaster

    Hi,

    No problem, we rechecked the Raspberry Pi support for OpenOCD and can try to clarify this. First of all, please try reading this article – it provides detailed steps with screenshots.

    Basically, you would need to build OpenOCD on your Raspberry Pi and run it there (our OpenOCD executable runs on Windows and hence it doesn’t indeed include the drivers that only make sense when running on Raspberry Pi).

    On the VisualGDB side, the “custom gdb stub” mode won’t work as it would expect the stub to run on Windows. Instead, please set the following options:

    Command <default GDB path>
    Arguments ——interpreter mi $(TargetPath)
    Target selection command target remote raspberrypi:<port>
    Start command continue

    Please note the double dash before “interpreter mi”.

    • This reply was modified 2 weeks, 2 days ago by  support.
    #20907

    TracesOfNut
    Participant

    HI,

    I tried following the suggested article and this time I had different problems. Previously I had done the same thing following a similar article and the ESp32 was being recognised ok by the openocd on the raspberry pi.  This time, I am getting a different error which I forgot to write down.

    Unfortunately I have had to stop trying for a short time due to work.  I will try again in a few days and report back.

    regards

    Justin.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.