Forum Replies Created
-
Posts
-
VisualMicro might be using a different debug mechanism that patches the code at compile-time to handle breakpoints and variable output, that is less flexible than the fully fledged gdb-based debugging, but would not rely on the Espressif’s GDB stub.
Please check what debug method the other tool is using (e.g. gdb stub, JTAG or the compile-time breakpoints) and ensure you are using the same settings with VisualGDB.
Also please do actually try different baud rates (especially 57600, 74880, 115200). The $T05#b9 message might be displayed under a different baud rate than the welcome banner and hence would not be properly visible.
If the $T05#b9 message is not shown despite trying different baud rates, the board you are using may not be supported by the gdb stub. Please contact Espressif for further details.
Hi,
Thanks for reaching out to us. Most likely, the debug probe internally exposes several USB interfaces (that technically count as separate USB devices) without reporting a unique serial number and that confuses the VisualGDB logic.
Please try locating the device in the Windows Device Manager (the debugger endpoint, not the virtual COM port and check its full hardware ID with VID, PID and MI strings). Then try editing the %LOCALAPPDATA%\VisualGDB\EmbeddedDebugPackages\com.sysprogs.arm.openocd\QuickSetup\interfaces.xml file to specify the UsbIdentity\Interface element that matches the MI value from the hardware ID.
Then please restart Visual Studio and see if the problem is resolved. If yes, please let us know the changes you made to interfaces.xml and we will update the version shipped with VisualGDB.
On a side note, using the CMSIS-DAP interface for debugging usually results in incredibly slow debugging performance (every single step can take about 5 seconds) due to the USB latency arising from the use of the USB HID class. If you have a feedback channel to the engineering team behind this Analog board, please consider suggesting that they update the firmware to expose an additional USB BULK interface and submit an OpenOCD patch to recognize it. It would require installing the WinUSB driver (as with many other debug probes), but would make debugging more than 10x faster.
Most likely, the gdb stub baud rate is configured incorrectly.
Please try opening the COM port with SmarTTY and resetting the board. The gdb stub should output the following text (indicating that it’s ready for gdb to attach):
$T05#b9
If you see anything different, please try using different baud rates to see if any of them works. Please also ensure you have followed all other steps from our ESP8266 Arduino tutorial.
Hi,
Please try creating an empty file at the path shown in the error message. Alternatively, please try using the following tool to uninstall VisualGDB: https://support.microsoft.com/en-us/help/17588/fix-problems-that-block-programs-from-being-installed-or-removed
Thanks for the detailed repro steps. It turns out, a recent change to the Arduino ESP8266 package indeed broke FLASH programming for some targets.
We have added a workaround for this to the following build: VisualGDB-5.5.1.3273.msi
Please share the exact steps to reproduce the problem from the very beginning (i.e. what exactly to specify on each page of the wizard while creating the project, what exact command to use in order to trigger the problem).
Hi,
Normally, VisualGDB would launch the Arduino builder that dumps various variables, letting VisualGDB reconstruct the command line. Unfortunately, it is not possible to change it explicitly, however in most of the cases, it should be derived correctly.
Please try checking via Tools->VisualGDB->Manage VisualGDB Packages whether you have multiple versions of the Arduino package installed. If this is the case, please try removing the old package versions. If it still doesn’t help, please let us know and we will investigate this further.
Sorry, if the 2 projects behave differently, something either about the project structure, or about the project settings is responsible for the difference.
Normally, the line should cause a special type of exception that would be intercepted by VisualGDB’s semihosting logic, however if it doesn’t happen, something interferes with the exception reporting mechanism, preventing VisualGDB from recognizing it.
The best way to diagnose this type or errors would be to start with a working project and slowly change it one step at a time until it is 100% equivalent to the broken one (i.e. uses the same sources, produces a comparable output, etc). If at this point the 2 projects still behave differently, simply use the new project file instead of the old one (although checking it into source control over the old one will likely reveal some differences).
Hi,
Normally component_compile_definitions() in the component’s file should work, so most likely the problem you are experiencing is caused by something else (e.g. source is used by a different component, or one of the CMakeLists files was overridden).
If you are not sure, please try reproducing the problem on a freshly created LEDBlink project. If it can be reproduced there, please try re-downloading the toolchain from scratch. If it still doesn’t work as expected, please check if the problem reoccurs when building the project outside VisualGDB and try submitting a bugreport to Espressif.
You can also use VisualGDB’s CMake debugger to step into the the component_compile_definitions() statement and check whether it works.
Hi,
It looks like you are using the regular Embedded Project Wizard that has been replaced by the Advanced ESP-IDF Project Wizard for ESP-IDF devices. Please try using the new advanced wizard instead.
Good to know it works. We suggested checking the peripheral clock in our first reply.
Regarding the registers, unfortunately it is not realistic to manually verify hundreds of registers definitions in hundreds of ST’s devices, hence we have to rely on an automated process of computing them, that has its limitations. If ST released better SVD files with detailed subregister definitions, we would gladly pick them up and use them instead of the header file parser. Please feel free to suggest that to ST.
Thank you for confirming your support status.
It looks like the register address is indeed correct. If the “test” variable has a value of zero after reading the data at 0x40000400, VisualGDB is indeed working as expected and the problem is caused by something else.The bit field definitions inside each register are computed by our BSP release logic based on parsing ST’s header files and do not reflect minor differences between peripheral instances (e.g. TIM3->CR2 vs TIM1->CR2). You can override this by locating the peripheral register definition file under %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs (see the MCUDefinitionFile element in the stm32.xml file in the project directory) and manually editing the register definitions you would like to change.
Hi,
This could happen if the register addresses were loaded incorrectly, or if the tool used for accessing the device (e.g. OpenOCD) fails to access the memory.
Please try locating one specific register that should be non-zero and verify that its address shown in the Hardware Registers window matches the documentation (or the address in the code).
Then try evaluating “*((int *)0x<address>)” in the Watch window. If you are using OpenOCD, please try running “mon mdw 0x<address>” in the GDB Session window. Then check if the output is still zero and if the OpenOCD window shows any warnings errors.
If the values are still zeroes, please try reading the register programmatically into a volatile variable (e.g. volatile int test = *((int *)0x<address>) and check its value. If it is also zero, the issue is not caused by the debugging logic and the registers do actually have a value of zero (e.g. if you have not enabled the corresponding peripheral’s clock).
