[support]

Hi,

Looks like you are setting a breakpoint in C:/Users/billy_000/Documents/Micromouse/2017/MicromouseTest/MicromouseOrientationTest/Src/main.c, but the actual path to the file as reported by gdb is C:/Users/billy_000/Documents/Micromouse/2017/MicromouseTest/MicromouseTest/Src/main.c.

Please double-check that you are using the correct file. You can also use the ‘breakpoint diagnostics’ button in the GDB Session window to automatically setup a path mapping so that VisualGDB can substitute the paths for you.

[support]

Hi,

Thanks very much for reporting this. It looks like the new gdb reports the ‘failed to resume session’ events slightly differently and this totally confuses VisualGDB.

We have fixed it in this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.14.1324.msi

It will also be included in the next maintenance release of v5.2.

[support]

Hi,

Sorry for the confusion. We will try to explain it from scratch.

Visual Studio uses a concept of configurations (e.g. Debug/Release) to build different variations of your program. You can switch those configurations via the Visual Studio toolbar (the default configuration is “Debug”). VisualGDB follows this concept and also allows having multiple configurations per project. If you open VisualGDB Project Properties and click “Configuration: Add” -> “Create a copy of current configuration”, VisualGDB will copy the build and debug settings from the current configuration (e.g. Debug) to another one (e.g. Debug2). You can then switch between those 2 configurations to quickly switch between different sets of settings.

After you create the “Debug2” configuration please go to the Project Settings page and select your target machine in the “Computer used for building and debugging” field. Then uncheck the “deploy executable on a different machine” checkbox. This will make Debug2 a “direct build” configuration that will allow running gdb directly on the Linux machine without the use of gdbserver. The Debug Settings page will change (e.g. the “Deploy the main executable to” will disappear).

As you are still building your project on the Windows machine, you would need to switch to the regular “Debug” configuration to build it, then try debugging it so that it is deployed and then switch to “Debug2” to debug it in the direct mode desribed above.

You can also avoid the need to create a separate configuration by upgrading to the Custom edition. Then you will be able to tweak the normal “Debug” configuration to run gdb on the target machine. This process is described in detail in this thread: https://sysprogs.com/w/forums/topic/debugging-child-process/

Hopefully this clarifies the necessary steps. If you need further details, please let us know.

[support]

Hi,

No problem. If you encounter further issues, feel free to create another topic.

[support]

Hi,

Please look in the GDB Session window in Visual Studio and switch it to “All GDB Interaction”. This should display the internal commands that VisualGDB sends to gdb. Then clear the window contents, try setting a breakpoint and check the output. If it does not explain what goes wrong, please post the output here and we will help you understand what is wrong.

[support]

Hi,

Yes, as those custom steps are defined differently in different projects, VisualGDB cannot automatically import them. Hence the easiest way to add equivalents to them would be to add add either custom pre-build actions, or custom MSBuild targets.

[support]

Hi,

Sorry about that. Those crashes are most likely caused by bugs in the Clang compiler that VisualGDB uses in its IntelliSense engine. Unfortunately Clang sometimes crashes when it encounters incomplete code. Those crashes are usually caused by something very specific that is hard to find proactively (one of the last examples was a crash when trying to compute a sizeof() of a structure inherited from another structure that could not be fully parsed due to a syntax error in the middle of its declaration).

Most of those issues are very trivial to pinpoint and fix if you could send us the dump file. We usually fix them in less than 24 hours from the report and send a hotfix immediately. Please send us the dump file that VisualGDB produces and we should be able to fix this quickly.

[support]

Yes, you can do that if you are using the Custom edition or higher. Please follow the steps below:

1. Check the ‘Allow choosing build/clean/debug command hosts independently’ checkbox on the Project Settings page of VisualGDB Project Properties
2. On the Debug Settings page specify the following settings:
   1. Start gdb in the following mode: Custom mode
   2. GDB launch command: gdb –interpreter mi –args <executable path to debug>
   3. Use a gdbserver: no
   4. Target selection command: (empty)
   5. Debugging start mode: use “run” command

 

[support]

Hi,

Sorry, we do not officially support building the embedded projects remotely. You should be able to import it in a custom mode and setup everything manually, but if you are not familiar with Linux internals, we strongly recommend copying the sources to the Windows side and importing them by following our regular import tutorial: http://visualgdb.com/tutorials/arm/import/

[support]

Hi,

Please double-check that you have the “Enable GDB stub” checkbox enabled in VisualGDB Project Properties and that your code calls gdbstub_init().

If this does not help, please try connecting to your COM port with SmarTTY or any other terminal program, enter the baud rate from the “GDB Stub Baud Rate” field in VisualGDB (normally 74880) and reset your board. Once GDB stub takes control, you should see the following output:

$T05#b9

If instead you see an error message, your board might be defective. If you don’t see anything or see total gibberish instead, please try experimenting with the baud rate (e.g. try 115200). Once you find out a baud rate that works, ensure you enter it in the GDB Stub Baud Rate field.

[support]

Hi,

No problem. We would advise to backup your .vgdbsettings file with the settings that work so that if it stops working again you could compare the settings and see what breaks it.

[support]

Hi,

Thanks, we have rechecked this. The ESP32 Bluetooth LE support requires some extra macros to be set in your project configuration file. Please replace your sdkconfig.h file with the following one:

/*
 *
 * Automatically generated file; DO NOT EDIT.
 * Espressif IoT Development Framework Configuration
 *
 */
#define CONFIG_TRACEMEM_RESERVE_DRAM 0x0
#define CONFIG_FREERTOS_CHECK_STACKOVERFLOW_NONE 1
#define CONFIG_MEMMAP_BT 1
#define CONFIG_SECURE_BOOTLOADER_DISABLED 1
#define CONFIG_ESPTOOLPY_FLASHFREQ "40m"
#define CONFIG_NEWLIB_STDOUT_ADDCR 1
#define CONFIG_TASK_WDT_CHECK_IDLE_TASK 1
#define CONFIG_ESPTOOLPY_FLASHSIZE "2MB"
#define CONFIG_INT_WDT 1
#define CONFIG_ESPTOOLPY_FLASHFREQ_40M 1
#define CONFIG_ESPTOOLPY_FLASHSIZE_2MB 1
#define CONFIG_FREERTOS_THREAD_LOCAL_STORAGE_POINTERS 1
#define CONFIG_LOG_DEFAULT_LEVEL_INFO 1
#define CONFIG_BT_RESERVE_DRAM 0x10000
#define CONFIG_ESP32_PANIC_PRINT_REBOOT 1
#define CONFIG_LWIP_MAX_SOCKETS 4
#define CONFIG_ESP32_ENABLE_STACK_BT 1
#define CONFIG_ULP_COPROC_RESERVE_MEM 0
#define CONFIG_ESPTOOLPY_BAUD 115200
#define CONFIG_INT_WDT_CHECK_CPU1 1
#define CONFIG_TOOLPREFIX "xtensa-esp32-elf-"
#define CONFIG_ESP32_RTC_CLOCK_SOURCE_INTERNAL_RC 1
#define CONFIG_ESPTOOLPY_BAUD_115200B 1
#define CONFIG_LWIP_THREAD_LOCAL_STORAGE_INDEX 0
#define CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN 16384
#define CONFIG_LOG_BOOTLOADER_LEVEL_WARN 1
#define CONFIG_TASK_WDT 1
#define CONFIG_MAIN_TASK_STACK_SIZE 4096
#define CONFIG_TASK_WDT_TIMEOUT_S 5
#define CONFIG_INT_WDT_TIMEOUT_MS 300
#define CONFIG_ESPTOOLPY_FLASHMODE "dio"
#define CONFIG_LOG_DEFAULT_LEVEL 3
#define CONFIG_FREERTOS_ASSERT_ON_UNTESTED_FUNCTION 1
#define CONFIG_ESPTOOLPY_FLASHMODE_DIO 1
#define CONFIG_PYTHON "python"
#define CONFIG_ESP32_TIME_SYSCALL_USE_RTC_FRC1 1
#define CONFIG_ESPTOOLPY_COMPRESSED 1
#define CONFIG_PARTITION_TABLE_FILENAME "partitions_singleapp.csv"
#define CONFIG_LWIP_DHCP_MAX_NTP_SERVERS 1
#define CONFIG_PARTITION_TABLE_SINGLE_APP 1
#define CONFIG_SYSTEM_EVENT_TASK_STACK_SIZE 2048
#define CONFIG_PARTITION_TABLE_CUSTOM_APP_BIN_OFFSET 0x10000
#define CONFIG_TASK_WDT_CHECK_IDLE_TASK_CPU1 1
#define CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ 240
#define CONFIG_FREERTOS_HZ 100
#define CONFIG_LOG_COLORS 1
#define CONFIG_FREERTOS_ASSERT_FAIL_ABORT 1
#define CONFIG_LOG_BOOTLOADER_LEVEL 2
#define CONFIG_ESPTOOLPY_BAUD_OTHER_VAL 115200
#define CONFIG_ESP32_DEFAULT_CPU_FREQ_240 1
#define CONFIG_ESP32_DEBUG_OCDAWARE 1
#define CONFIG_FREERTOS_BREAK_ON_SCHEDULER_START_JTAG 1
#define CONFIG_BT_ENABLED 1
#define CONFIG_FREERTOS_CORETIMER_0 1
#define CONFIG_PARTITION_TABLE_CUSTOM_FILENAME "partitions.csv"
#define CONFIG_FREERTOS_ISR_STACKSIZE 1536
#define CONFIG_OPTIMIZATION_LEVEL_DEBUG 1
#define CONFIG_SYSTEM_EVENT_QUEUE_SIZE 32
#define CONFIG_APP_OFFSET 0x10000
#define CONFIG_MEMMAP_SMP 1
#define CONFIG_ESPTOOLPY_PORT "/dev/ttyUSB0"

Then please use the following linker script to link your Bluetooth LE code:

MEMORY
{
  /* All these values assume the flash cache is on, and have the blocks this uses subtracted from the length
  of the various regions. The 'data access port' dram/drom regions map to the same iram/irom regions but
  are connected to the data port of the CPU and eg allow bytewise access. */
  /* IRAM for PRO cpu. Not sure if happy with this, this is MMU area... */
  iram0_0_seg (RX) : org = 0x40080000, len = 0x20000
  /* Even though the segment name is iram, it is actually mapped to flash */
  iram0_2_seg (RX) : org = 0x400D0018, len = 0x330000
  /* Shared data RAM, excluding memory reserved for ROM bss/data/stack.

     Enabling Bluetooth & Trace Memory features in menuconfig will decrease
     the amount of RAM available.
  */
  dram0_0_seg (RW) : org = 0x3FFB0000 + 0x10000,
                                     len = 0x50000 - 0x0 - 0x10000
  /* Flash mapped constant data */
  drom0_0_seg (R) : org = 0x3F400010, len = 0x800000
  /* RTC fast memory (executable). Persists over deep sleep.
   */
  rtc_iram_seg(RWX) : org = 0x400C0000, len = 0x2000
  /* RTC slow memory (data accessible). Persists over deep sleep.

     Start of RTC slow memory is reserved for ULP co-processor code + data, if enabled.
  */
  rtc_slow_seg(RW) : org = 0x50000000 + 0,
                                     len = 0x1000 - 0
}
/* Heap ends at top of dram0_0_seg */
_heap_end = 0x40000000 - 0x0;


INCLUDE esp32.common.ld
INCLUDE esp32.rom.ld
INCLUDE esp32.peripherals.ld

[support]

Hi,

Sorry, GNU tools like GDB are often unreliable and some versions may simply be not compatible with certain OS versions. If the version 7.12 does not work, the only advice we can give is to revert back to v7.10. As long as you are using the new method to run gdb directly on the target, both 7.10 and 7.12 should work.

[support]

Hi,

Thanks for posting this, it looks like our bug. We could not reproduce it on our side though.

Could you please check if modifying our version of the linker script to align the fs_data contents also helps?

.data : AT(_sidata)
 {
 . = ALIGN(4);
 _sdata = .;

PROVIDE(__data_start__ = _sdata);
 *(.data)
 *(.data*)

. = ALIGN(4);  #<=================== Insert this line
PROVIDE(__start_fs_data = .);
KEEP(*(.fs_data))</strong>
PROVIDE(__stop_fs_data = .);

. = ALIGN(4);
 _edata = .;

PROVIDE(__data_end__ = _edata);
 } > SRAM

If yes, we will release a hotfix for the BSP.

[support]

Hi,

Sorry, looks like the virtual terminal mechanism used by VisualGDB to redirect the program output is broken on your Linux distro:

&”/dev/pts/18: No such file or directory.\n”

The only workaround we could suggest is to explicitly forward the program output to a file:

1. Create an empty file on the Linux machine (e.g. /tmp/output) by running the following command on Linux via SmarTTY: echo > /tmp/output
2. Add the following command to the GDB commands after selecting a target (Additional GDB Commands page): tty /tmp/output

Note that you will not see the program output in real time then as it will be forwarded to a file.

[Author]

Posts