Forum Replies Created
-
Posts
-
Hi,
ESP32 has 3 different watchdogs that could be restarting the CPU once it is stopped and we experienced similar behavior before we modified the ESP32 OpenOCD to explicitly disable them:
xtensa_write_hwreg(target, 0x3FF5F064, 0x50d83aa1); //TIMG1 WDT xtensa_write_hwreg(target, 0x3FF5F048, 0); xtensa_write_hwreg(target, 0x3FF60064, 0x50d83aa1); //TIMG2 WDT xtensa_write_hwreg(target, 0x3FF60048, 0); xtensa_write_hwreg(target, 0x3ff480a4, 0x50d83aa1); //RTC WDT xtensa_write_hwreg(target, 0x3ff4808c, 0);
Our best guess is that in your case this mechanism does not work. Unfortunately the ESP32 tools are currently not very reliable and do not provide good troubleshooting mechanisms, so the only advice we could give is to do some black box experiments to understand what triggers the problem.
Hi,
No problem. This is somewhat counter-intuitive and we will probably add a warning for this in one of the later releases.
Hi,
Yes, please add *.xml to the “copied file masks” under VisualGDB Project Properties -> Project Settings.
Hi,
The VCP_write() function is provided by us and it’s based on the original sample from ST and it indeed contains a bug with HS instead of FS. The correct version should look like this:
#ifdef USE_USB_HS enum { kMaxOutPacketSize = CDC_DATA_HS_OUT_PACKET_SIZE }; #else enum { kMaxOutPacketSize = CDC_DATA_FS_OUT_PACKET_SIZE }; #endif int VCP_write(const void *pBuffer, int size) { if (size > kMaxOutPacketSize) { int offset; int done = 0; for (offset = 0; offset < size; offset += done) { int todo = MIN(kMaxOutPacketSize, size - offset); done = VCP_write(((char *)pBuffer) + offset, todo); if (done != todo) return offset + done; } return size; } USBD_CDC_HandleTypeDef *pCDC = (USBD_CDC_HandleTypeDef *)USBD_Device.pClassData; while (pCDC->TxState) {} //Wait for previous transfer USBD_CDC_SetTxBuffer(&USBD_Device, (uint8_t *)pBuffer, size); if (USBD_CDC_TransmitPacket(&USBD_Device) != USBD_OK) return 0; while (pCDC->TxState) {} //Wait until transfer is done return size; }We have updated this internally and will include the fix in the next release of the BSP. Regarding packets larger than CDC_DATA_FS_OUT_PACKET_SIZE, they do sometimes work, but may not be fully supported by the hardware and hence may cause strange effects, so we would not recommend using them.
Hi,
It’s hard to say what is causing this without more details. Normally when VisualGDB runs the ‘mon reset init’ command (unless you have disabled chip reset via Debug Settings), the stack pointer should be reset based on the contents of the interrupt table.
Please try running the ‘mon reset init’ command manually and check if the output shows the correct sp value:
xPSR: 0x01000000 pc: 0x080026bc msp: 0x20020000
If yes, please check that the OpenOCD window contains similar text at the beginning of the log:
adapter speed: 1800 kHz stm32f4x.cpu: target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000
Hi,
This looks like some kind of a symbol load problem. Please check if gdb shows your plugin in the ‘info symbols’ command output. If yes, please try adding the path to the .so file with symbols via the set solib-search path command so that gdb can load symbols for it.
Hi,
First of all, if your evaluation license runs out before you get things to work, please contact our sales and they will give you a trial extension.
Regarding the “no symbol table” error, most likely your program was built without the “-ggdb” argument and hence does not contain information required to map the disassembly back to the source code. If you are using VisualGDB Project Wizard to generate a project, it should setup everything automatically, but if you are importing a 3rd-party project, you may need to adjust its build files.
If the project is built with GNU Make, please search the Makefiles in different directories for lines defining CFLAGS (you can search for -O1, -O2 and -O3 options that define the optimization level). Once you locate them, please add -ggdb to the list of CFLAGS and rebuild the project. If this does not help, please enable verbose build logging and double-check that the -ggdb argument actually gets passed to gcc.
If you are not sure, feel free to post further details here and we will point you to the right direction.
Hi,
Thanks for clarifying this. Looks like in the latest STM32 BSP there is a small bug that prevents the oscillator speed from the wizard from being set in the project configuration.
Please locate the stm32xxx_hal_conf.h file in your project and then double-check the HSE_VALUE defined there:
#if !defined (HSE_VALUE) #define HSE_VALUE ((uint32_t)25000000U) /*!< Value of the External oscillator in Hz */ #endif /* HSE_VALUE */
Also the default LEDBlink project does not automatically configure the PLL. To do that you can generate the configuration code using the STM32Cube software, or copy it from one of other examples for your board. The typical clock configuration function looks like this:
static void SystemClock_Config(void) { RCC_ClkInitTypeDef RCC_ClkInitStruct; RCC_OscInitTypeDef RCC_OscInitStruct; /* Enable HSE Oscillator and Activate PLL with HSE as source */ RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PREDIV = RCC_PREDIV_DIV1; RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6; if (HAL_RCC_OscConfig(&RCC_OscInitStruct)!= HAL_OK) { Error_Handler(); } /* Select PLL as system clock source and configure the HCLK, PCLK1 clocks dividers */ RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1); RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1; RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1; if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1)!= HAL_OK) { Error_Handler(); } }Hi,
It could be caused by updating the ESP32 IDF then.
You can try the older version by downloading the older toolchain from here: http://gnutoolchains.com/esp32/. There is no need to reinstall VisualGDB.
Hi,
We have encountered similar behavior with ESP8266 – some firmware (specifically AT commands) triggered some undocumented hardware mode that prevented the breakpoints from being handled properly. Unfortunately this is something beyond our control so the only advice we could give here is to experiment with moving the functions to RAM and setting explicit breakpoints (asm(“break 1,1”)) in various functions to understand what triggers this mode.
Hi,
Looks like you might be compiling the code with the -O0 optimization level that triggers a bug in the ESP32-IDF.
Please try switching it to -Og via Visual Studio Project Properties -> C/C++ -> Optimization.
Hi,
The ESP32 OpenOCD sometimes shows this message if one of the cores is not stopped properly. Please try running the “mon targets” command to see if both cores are stopped. You can then forcibly stop them by running “mon halt”.
Hi,
Please ensure that you are using the latest VisualGDB 5.2 and the new MSBuild subsystem.
Alternatively you can try manually setting the optimization level to -Og instead of -O0 and specifying the -std=gnu++11 language standard.
Hi,
Sorry about that. First of all please note that the ESP32 chip is very new and often behaves unpredictably, so this is to be expected.
Our best advice here would be to try something very simple and see if this works. Does building and programming a basic “LEDBlink” project with VisualGDB work? If no, does flashing the same ELF file with esptool.py work?
If you can confirm that the file built with VisualGDB does not work even when flashed with esptool, please ensure that you are using an unmodified toolchain from us and that the optimization is set to -Og, not -O0.
Hi,
We are sorry about the inconvenience. You can easily use the VisualGDB test functionality to test complex libraries as well; simply create a test application that will reference your library and you can write tests for the library functions.
Regarding the “ReadFile failed”, this refers to a pipe between the component that controls debugging and the one responsible for selecting tests and forwarding output from them. We would be happy to help you pinpoint this if we knew at what point the problem happens and what other information is shown along with the error. So if you ever feel like trying this again, please let us know and we will help you troubleshoot this.
