[support]

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.

[support]

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.

[support]

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(); 
  }
}

 

[support]

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.

[support]

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.

[support]

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.

[support]

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”.

[support]

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.

[support]

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.

[support]

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.

[support]

Hi,

If VisualGDB does not show any extra error output, most likely the gcc executable simply fails to start. This could be if the toolchain is corrupt or your antivirus is blocking it. Please try running the “arm-none-eabi.gcc.exe -v” from the toolchain manually. Does it successfully output the version? If yes, what happens if you ignore the toolchain testing error and proceed with creating and building the project?

[support]

Hi,

This error is a generic one that indicates a hardware exception (e.g. trying to read an invalid address) and usually happens for simple projects when the project configuration does not match the board (e.g. the configured memory size is larger than the actual memory size).

To track it down, please check the call stack window to see where in the code it happens. If this does not work, please open the Embedded Debug Settings page of VisualGDB Project Properties, select “step into new instance-> entry point” and start debugging with F10 instead of F5. Then you should be able to step through the startup code and understand what causes the error.

If you are not sure, feel free to post the details about the error here and we will help you resolve it.

[support]

Hi,

Most likely the HSE_VALUE macro defined in your project configuration does not match the speed of the clock oscillator on your board. Please double-check your project configuration and the board schematics.

[support]

Hi,

Unfortunately it’s hard to say what is causing this based on the message alone. Looks like one of the paths specified in the settings is wrong. Can you pinpoint a specific step that triggered the problem?

[support]

Hi,

No problem. BTW, you can conveniently edit the signal settings by pressing the ‘signals’ button (with the lightning icon) in the GDB Session window.

[Author]

Posts