{"id":9551,"date":"2016-11-22T23:12:16","date_gmt":"2016-11-22T22:12:16","guid":{"rendered":"https:\/\/sysprogs.com\/w\/?p=9551"},"modified":"2016-11-22T23:38:31","modified_gmt":"2016-11-22T22:38:31","slug":"limitations-of-the-esp32-debugging","status":"publish","type":"post","link":"https:\/\/sysprogs.com\/w\/limitations-of-the-esp32-debugging\/","title":{"rendered":"Limitations of the ESP32 debugging"},"content":{"rendered":"

We have just added support for the new ESP32 chip to VisualGDB. While VisualGDB allows building projects, setting breakpoints and debugging your ESP32\u00a0code out-of-the-box, the ESP32 tools come with a few known limitations that may interfere with debugging.\u00a0In this post I will summarize them and show known workarounds.<\/p>\n

<\/p>\n

Reset behavior<\/h2>\n

The biggest problem of the ESP32 chip is that it cannot be reliably reset into a predictable\u00a0initial state. Programming the SPI FLASH requires putting the chip in a state where the background tasks are stopped, FLASH is initialized properly and the interrupts are disabled.\u00a0Unlike ARM\u00a0devices that enter this state immediately after reset, ESP32 does not allow\u00a0doing it easily.\u00a0Resetting just the CPU leaves the peripherals in an unpredictable state that often results in a crash and resetting the entire chip immediately starts the CPU, so by the time VisualGDB can stop it, it has already begun\u00a0running some code.<\/p>\n

VisualGDB works around this by\u00a0doing a chip reset and halting both CPUs some time after it, but this\u00a0does not work 100% reliably.<\/p>\n

If you encounter a\u00a0situation where your FLASH memory cannot be programmed, try the following steps to troubleshoot it:<\/p>\n

    \n
  1. Put the chip in the bootloader mode (hold the bootloader button, press the reset button).<\/li>\n
  2. Start JTAG debugging. The memory should get programmed, but the\u00a0chip will not leave the bootloader mode without\u00a0a physical reset.<\/li>\n
  3. Reset the chip by pressing the Reset button.<\/li>\n
  4. Select “do not program FLASH” in VisualGDB Project Properties and start JTAG debugging again<\/li>\n<\/ol>\n

    Breakpoints in FLASH<\/h2>\n

    The ESP32 chip has only 2 hardware breakpoints. This means that you cannot set more than 2 simultaneous breakpoints in the code that\u00a0resides in the SPI FLASH.\u00a0To work around this you can move some of your functions from FLASH to RAM:<\/p>\n

    void __attribute__((section(\".iram1\"))) ramfunc()\r\n{\r\n    \/\/...\r\n}<\/pre>\n
    VisualGDB will automatically detect the code that is placed in RAM and will use software breakpoints instead of hardware ones for it.<\/p>\n
    Breakpoints in RAM<\/h2>\n
    Unlike ESP8266 where software breakpoints in RAM just work, the ESP32 makes things a bit trickier due to\u00a0having 2 cores. \u00a0They will work flawlessly if they are triggered on the same core\u00a0that was active when setting them. If a different core triggers a\u00a0software breakpoint, OpenOCD will not handle it correctly will display it as\u00a0a random stop in a random place:\"multicore\"<\/a><\/p>\n
    Although this is\u00a0annoying, it does not mean the end of the world. You can switch to the other core via the Threads window in Visual Studio and see the code that triggered the breakpoint:\"core2\"<\/a><\/p>\n
    Viewing local variables and call stack will work, but trying to continue\u00a0debugging will result in a random effect from stopping at\u00a0the same place in code to crashing gdb. The workaround would be to disable the breakpoint, optionally set another on on the next line, resume execution with F5 and reenable the original breakpoint once the next breakpoint is hit.<\/p>\n
    We have experimented with modifying OpenOCD to report the correct core in the ‘session stopped’ event, but this often results in crashing the firmware, so as of November 2016,\u00a0the core that triggered the breakpoint needs to be selected manually.<\/p>\n
    Stepping into functions does not work<\/h2>\n
    This is another unfortunate limitation of the ESP32 GDB. Trying to step into and over function calls often\u00a0ends up with just resuming the execution. The workarounds that work are:<\/p>\n