[support]

Hi,

If the files are referenced by the gpdsc file, it could be our bug. Please feel free to attach the generated gpdsc file (and files copied by STM32CubeMX) and we could quickly investigate whether this is something we could fix.

[support]

Hi,

ESP8266 supports only one hardware breakpoint. If you would like to set more breakpoints, please try moving some of your functions to RAM by declaring them with ICACHE_FLASH_ATTR.

If you don’t want to use the gdb stub, simply disable the call to gdbstub_init().

Regarding the empty com port list, please try attaching a screenshot of this so that we could see what is going on.

[support]

Hi,

Sorry, avrdude unfortunately doesn’t support debugging. Our best advice would be to try patching AVaRICE to add support for your device (it conveniently stores device descriptions in a single table in the source code), however we cannot guarantee that this would work.

[support]

Hi,

No problem, we have added an automatic warning for this case in the upcoming v5.3R8.

[support]

Hi,

Switching FLASH mode to “DIO” likely did the trick.

Regarding the breakpoint issue, please attach a full GDB log as shown here so that we could help you diagnose this.

[support]

Hi,

We haven’t tested VisualGDB with LL projects yet, however this looks like the GPDSC file references some sources that were not copied by the STM32CubeMX tool. You could check this by examining the gpdsc file (or we could check this for you if you could attach the screenshots of your STM32CubeMX settings). If it appears that STM32CubeMX indeed doesn’t copy the files, please file a bug report with ST. If the files are copied to a different location or a named differently, please let us know and we will add a workaround.

[support]

Hi,

No problem, we have a detailed tutorial explaining how to use the dynamic analysis to verify the stack size: https://visualgdb.com/tutorials/arm/stack/

[support]

Hi,

No problem, we’ve edited the previous reply to fix the encoding.

[support]

The settings should be pretty straight-forward (source/target directories, transfer masks), so it’s hard to tell anything beyond that without knowing more details. Please try attaching a screenshot of your transfer settings and also the path of the XML file on the Windows machine and we will try to suggest what could be wrong.

[support]

Hi,

No problem, please find the answers to your questions below:

1) You can build a custom BSP with your own mbed version by using our open-source BSP generator. However as the mbed internals are rapidly changing, it may not work out-of-the-box with every version you would like to try, so you may need to adjust it accordingly (we periodically refresh it to support the latest mbed releases, but trying it with any other version is at your own risk).

2) This could be caused by a typo in toolchain.xml. Please post the contents of your toolchain.xml and the generated mbed.xml and mbed.mak and we walk you through resolving this.

3) Looks like this indeed broken for GNU Make. Please try this build: VisualGDB-5.3.17.1950.msi

5) VisualGDB can import your projects in 2 modes: generate a managed Makefile for it (that will have VisualGDB-specific structure, so VisualGDB can edit parts of it automatically in response to changing options via GUI) and import it as a generic command-line project (VisualGDB will run the build command line specified by you, but won’t make any assumptions about the project internals). We recommend the first import mode for long-term solutions and the second import mode for experimenting and hacking, hence the memory usage output is only supported in the first one. Let us know if you need more examples.

[support]

Hi,

Thanks, we have confirmed this. Looks like GNU Make  doesn’t properly handle values with spaces regardless of the escaping.

As a workaround please try adding the following code directly to CFLAGS/CXXFLAGS:

-D__int64="long long"

• This reply was modified 7 years, 7 months ago by support. Reason: sample code encoding

[support]

Hi,

Good to know it works. Please feel free to follow up in the JTAG topic and we will try to suggest further diagnostic steps. E.g. we noticed that the JTAG test shows the “halted, PC=xxxx” line, while the actual debug session doesn’t. Can you confirm that behavior 3 times in a row (i.e. debug, test, debug, test, debug, test). If the results are not consistent, this is likely due to flaky wiring.

[support]

Hi,

Please try using the \” syntax.

[support]

Hi,

The easiest way to do this would be to select the “bootloader + gdb stub” debug method. If you don’t actually include a debug stub, you will be able to program your firmware, but not debug it. If you do include the stub, you will be able to debug it as well. You can read more about the gdb stub in this tutorial: https://visualgdb.com/tutorials/esp8266/gdbstub/

[support]

Hi,

Thanks for the update. Let us know if you decide to give it a try with another board.

[Author]

Posts