JTAG difficulties #77
Comments
|
@gojimmypi - Thanks for the detailed information.
I don't think there's anything in the Golioth code using those pins, but if you've had success with JTAG debugging in other projects (e.g. As a test, can you see if your issue exists on the basic shell example in esp-idf? https://github.com/espressif/esp-idf/tree/master/examples/system/console/basic. And a second test - disable the shell by commenting out this line, and see if the issue exists: https://github.com/golioth/golioth-firmware-sdk/blob/main/examples/esp_idf/golioth_basics/main/app_main.c#L34 |
|
Hello @ncmiller and thank you for the prompt reply!
... and you are right. those code segments were not at all the root cause. Thanks for the tip & saving me the time of going and looking for (non existent) GPIO initialization. But given your comment, I was wondering what else might be different? I started looking at your Turns out, if I remove these lines from the sdkconfig.defaults, then JTAG works great: Given the TODO comment, it looks like you folks have been having some challenges with BLE, and I saw similar issues. The line of particular interest is this one: I do recall seeing an odd bootloader prompt in the UART output when JTAG was not working. There's no mention of that setting being problematic in the docs, so I'm not sure if that's the only setting or perhaps the combination of disabling Bluetooth. I wonder if there's RAM overhead for JTAG debugging? |
|
Here is further evidence that the
I wonder if the JTAG reset to program the device causes this rollback operation? |
Have you tried disabling them in isolation, i.e. disabling Bluetooth but enabling
For those app rollback notes, I believe they're only relevant if there is a pending OTA update, meaning that
If the state is I'd be surprised if |
|
The issue seems kind of similar to espressif/openocd-esp32#223. It might be worth checking whether your openocd version is up to date with https://github.com/espressif/openocd-esp32/releases/tag/v0.11.0-esp32-20220706. Another idea would be to slow down the JTAG clock to see if it changes anything. You're running at 13 KHz, so maybe try 10KHz or 8KHz. |
Golioth Firmware SDK Commit Hash
ec34837
Platform/OS
ESP IDF Release v5
WSL and Windows with VisualGDB;
Visual Studio 2019 with VisualGDB Custom Edition version 5.6R9 (build 4777).
Hardware Target
ESP32-WROOM32-32U on the ESP32_DevKitC_V4
What host OS are you using?
Windows 10
Current Behavior
I'm taking the golioth_basics demo for a test drive. The app itself works great as described in my tweet thread.
The challenge I've encountered is that once that firmware is loaded, future instances of JTAG debugging seem to be impossible. The only way I have found to resolve this problem is to flash a simple hello world on to the ESP32 and then load the Golioth firmware. As noted the JTAG debugger works the first time, but subsequent sessions refuse to connect. I'll see this message until it times out:
Here's a picture of my setup with the Tigard:
I have a blog that describes the setup. In particular, I am using these pins:
I've seen this "impossible to connect JTAG" before: typically it is when those same GPIO pins are initialized and/or used for something other than JTAG. I'll be taking a look, but perhaps one of the active Golioth developers familiar with the code already knows the answer?
I'm fairly certain that the root cause is in the Golioth codebase, as I use this exact setup on a very regular regular basis and never see this particular problem with other source code.
If indeed this is a known "preinitialize the GPIO pins", perhaps there's an option to not do that during debugging?
Expected Behavior
JTAG debugging should connect and single step the code every time, regardless of what firmware was previously installed.
Steps To Reproduce
Simply press the "step into" button in Visual Studio:
Normally the JTAG programmer will flash the firmware and step into the code
Logs, console output, or any kind of debug information
edit: here's the GDB log when it fails to connect. During this time, the Golioth software on the ESP32 appears to be running properly and uninterrupted:
Note the curious
Too many flash mappings 1931505486! Must be 2.message. Cause or effect?The text was updated successfully, but these errors were encountered: