[support]

Hi,

Sorry, unfortunately not much. As this kernel version was discontinued ~7 years ago, most modern tools will likely not support it anymore, so we would advise switching to a newer system that runs a 3.x or a 4.x kernel.

[support]

Hi,

Please try exporting your VS color settings via Tools -> Import and Export Settings and then restoring them if the VisualGDB installation resets them.

[support]

Hi,

Thanks for checking this. If the “print” command works, this is likely an issue between VisualGDB and gdb, so we should be able to fix it easily.

Please create a diagnostic gdb log showing the incorrect value obtained via the “watch” window and the correct value for the same variable obtained via the “print” command and we should be able to see what is going on.

[support]

Hi,

Sorry, we don’t support older kernels officially as they are missing many APIs required by various parts of VisualKernel (e.g. our Ethernet debugging driver and the fast module enumeration driver). As we provide source code for both of those components, you might be able to patch them to run under older kernels, but we won’t be officially supporting the 2.4 kernel as it is no longer actively maintained and not used in modern distros.

[support]

Hi,

If you are using the Segger GDB stub, yes, the stub is responsible for reading the ITM-related registers and generating the output stream shown in the Raw Terminal window, hence it’s up to the stub to control the exact output format. Please check with Segger whether there is an option for removing the that. Another option would be to create a basic tool that will work like a proxy server between the gdb stub and the raw terminal, removing the extra symbols (you would need to know where exactly the Segger stub inserts the channel number bytes).

[support]

 

Hi,

Thanks for pointing out the missing sram_layout for the vendor samples. Indeed it was only defined when using the HAL or StdPeriph framework that is used with regular projects, but not with lightweight STM32CubeMX samples. We will also fix this in the upcoming BSP update.

The RAMDTCM_BASE  issue looks like a conflict between the sample-specific system file and the default linker script used by VisualGDB. We will retest this as a part of our BSP tests and will ensure that the correct linker script is used with the lightweight samples.

It’s great to hear that you are happy with VisualGDB. Let us know if you encounter any further issues, or have any suggestions and we will be happy to make VisualGDB even better.

[support]

 

OK, we have done some investigation on this. Although we were not able to locate the problem yet, we can walk you through pinpointing it. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2403.msi

First of all, please check that adding the header files to Solution Explorer adds their directories as COMPONENT_SRCDIRS to component.mk (although there are no source files in those directories, VisualGDB will use the COMPONENT_SRCDIRS statement to locate the headers).

If yes, please open View->Other Windows->VisualGDB Diagnostics Console and reopen the project. Check for diagnostic lines like “Will search for headers for <…> in <…>” and “Found <…> header files for <…>”. Do those lines make sense (i.e. do some paths look incorrect)?

If you are not sure, please let us know the full paths of the header directories, attach your component.mk and the entire diagnostic log.

 

[support]

Hi,

Sorry for the delayed reply. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.4.2402.msi

The Arduino projects are indeed more dependent on the serial connection, so we have added an equivalent of the Raw Terminal (called Arduino Serial Terminal) that uses the COM port used for communicating with the device. This terminal will work on all VisualGDB editions, but only for Arduino projects.

Resetting the Arduino target from the toolbar/terminal sounds reasonable, however it looks like something platform-specific (i.e. there is no universal command line that will do it for all supported targets). We could add a setting specifying the reset sequence with commands like “connect at a specified BPS”, “set/clear various UART signals”, “send bytes”, etc. In one of the next major releases we could include out-of-the-box definitions for this reset sequence for popular targets, although initially you would have to provide it manually (e.g. by looking through esptool.py sources). Would that be a reasonable workaround?

With OpenOCD, unfortunately the ESP8266 Arduino core modifies some internal registers in a way that completely blocks JTAG debugging. We have contacted Espressif regarding this and could not get any reply from them. As ESP8266 is generally less reliable than the newer ESP32 chip (that doesn’t have this issue and works with JTAG), we would advise switching to it instead, or using the ESP8266 gdb stub, that is also very limited when used with the Arduino core (we will publish a tutorial soon explaining the limitations).

We have added the rest of the features/fixes as you described them. Thanks for your suggestions and feel free to get back to us if you have more ideas on making Arduino support more convenient. The Arduino project subsystem is very new and we appreciate any feedback that helps us make it better.

Regarding the forum threads, it is normally easier for other users to find relevant threads if separate issues are reported in separate threads, but you don’t need to worry about it – we can always split the thread from our side if we post a workaround that would be otherwise hard to find based on the original title.

[support]

 

Thanks for the explanation. The “monitor” commands are handled by the gdb stub used together with VisualGDB (typically either the Segger GDB stub, or OpenOCD). We would advise checking the Segger gdb stub documentation (or OpenOCD source code) for options that might turn on the ITM output decoding.

[support]

Hi,

Thanks for the very detailed description and sorry for the inconvenience. The issue is actually caused by the following code in the system_stm32f7xx.c file:

#ifdef VECT_TAB_SRAM
 SCB->VTOR = SRAM1_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */
#else
 SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */
#endif

It checks whether the project is built to run from FLASH or RAM and then sets the interrupt vector table register accordingly. If the code is running from RAM, but the vector table is pointing in FLASH, the interrupt controller won’t be able to invoke the correct interrupt handlers and hence SysTick_Handler() won’t be called.

The ST software packages use different variable name to distinguish FLASH/RAM configurations on different families (sram_layout on most families, but VECT_TAB_SRAM on F7 and H7) and VisualGDB handles it by patching the default system file on F7 and H7 to check the sram_layout instead. This indeed causes the problem you described when using STM32CubeMX samples that come with their own system file.

We will fix this in the upcoming STM32 BSP update. As a workaround, please define VECT_TAB_SRAM manually via VisualGDB Project Properties -> MSBuild Settings -> Preprocessor macros.

Let us know if you encounter any further problems and we will be happy to help.

[support]

Hi,

Normally this is something handled by the toolchain/gdb. Could you please double-check that running the “print test_struct.var” command in the gdb session shows the same wrong output? If yes, please check if your code is built without optimization. Debugging optimized code is always inaccurate as gcc often eliminates unused variables and reuses fragments of the code.

[support]

Hi,

It looks like the software you are using to decode the ITM output doesn’t strip the channel number from the stream, thus prefixing every transmission with 01. Depending on the exact software, there might be a setting to do that and display just the raw output.

[support]

Hi,

Sorry, we have rechecked this and could not reproduce any problem. Please try switching the terminal to the hex mode and ensure that the ‘escape’ character is transmitted properly.

E.g. try transmitting exactly the line shown in our previous post and verify that the HEX view shows the following output:

74 65 73 74 0a 1b 5b 31 3b 32 48 32 1b 5b 31 3b 31 48

[support]

Hi,

Sorry, this is not supported directly. We have done some basic experiments with the 2-core LPC43xx devices and the biggest problem we encountered was that the 2 cores required 2 separate copies of the C library (compiled for 2 slightly different instruction sets) that could not be easily merged into a single ELF file, so the current out-of-the-box support it limited to the M4 core.

As a workaround, please consider following the legacy device tutorial to create a project manually (or simply import one of the code examples from NXP) and then edit the OpenOCD configuration script for the MCU to leave out only the M0 target (or use Segger J-Link and pick “LPCxxxx_M0” as the target device). Although, due to the limitations of the gdb, you won’t be able to easily debug both cores at the same time.

[support]

Hi,

Yes, the X server might be running on a different port. Please try starting a GUI terminal (e.g. xterm) via the USB keyboard/HDMI port on Raspberry Pi, and type “echo $DISPLAY” to see the display number used by your board. If the number is not 0, simply copy it to the corresponding field in VisualGDB Project Properties.

Please also ensure that the user name used in VisualGDB to connect to your Raspberry Pi matches the user account running via the HDMI port (normally ‘pi’).

[Author]

Posts