Forum Replies Created
-
Posts
-
Hi,
This is expected as GNU Make uses absolute paths in the dependency files. Please try rebuilding the project (Build->Rebuild All) instead of just building it.
Hi,
It’s hard to say why this happens without seeing the debug log. Please enable gdb logging on the Advanced GDB Settings page and check the debug log for messages explaining the unexpected end of session.
If you are not sure, please attach the debug log here and we will help you pinpoint the problem.
Hi,
Thanks for your feedback. Although this is not possible now, we have added a note to the v5.3 feature list and will add an option to start renaming via a menu command.
Hi,
As usual with ESP8266, it’s hard to say for sure. Something on the board may be interfering with JTAG or something in the board firmware may be interfering with FLASH programming. As those things are not really documented, unfortunately we can only guess here.
BTW, you can use VisualGDB with the UART gdb stub as well (see this tutorial). This mode does not involve JTAG and should work if VisualMicro works as well.
Also feel free to attach the full gdb log so that we could check for common errors.
Regarding other questions:
- The large project.bin file is actually not needed. It’s a default binary file containing ALL the sections from the image. It is useful on other targets like ARM or MSP430, but not on ESP8266 or ESP32. You can disable it via the VS Project Properties (Generate binary files = No). Manually programming the other 2 files should be sufficient (you can also use <SysGCC>\esp8266\esp8266-bsp\ESPImageTool.exe to program an ELF file via a COM port).
- We never had to change the default sector/erase block sizes, but as those values are not well documented, we made them editable.
- The names for the FLASH modes, frequencies, sizes, C1/C2 come from the esptool.py provided by Espressif and to our best knowledge specify the FLASH parameters that the ESP8266 device will use. On VisualGDB side selecting one of those changes the values in the ESP8266 image header (which is undocumented) similarly to what esptool.py does. Please double-check the exact semantics and meanings of those with Espressif.
- The reset options you mentioned do not apply to JTAG programming. In fact, lack for reliable reset (that stops the CPU immediately after resetting before the ROM starts various background processes) is one of the main reasons why JTAG debugging is very unreliable compared to the GDB stub.
Hi,
This could happen if your firmware is putting the CPU to the sleep mode.
Please try the steps described in the following tutorial to enable the “connect under reset” mode: https://visualgdb.com/tutorials/stm32/sleep/
Hi,
Based on the log snippet you attached, this should work. Perhaps it is an extern “C” problem?
Hi,
This does indeed go beyond the scope of our product support, so our best advice would be to stop the debug session with the “Break all” command and check if the program is stopped on an unhandled exception or something similar.
If not, please consider asking on the STemWin forums as they should have a better knowledge of the library internals.
Hi,
Most likely some of the network parameters (IP address, subnet mask, gateway, etc) is not configured properly. Please refer to your University documentation on network configuration and connectivity to figure out correct IP addresses and network configuration.
Hi,
Thanks for clarifying this. It is actually a known behavior of gdb. When jumping to a line with a breakpoint, the breakpoint will get triggered after resuming the program as if the line got reached naturally.
It should not interfere with anything else; simply press F5 or F10 again to continue debugging.
Hi,
When we tested the OpenOCD SWO support with ST-Link, we could not get it to work reliably and gave up. There are several discussions online describing the OpenOCD commands to use (e.g. this), but we cannot recommend this approach due to low reliability.
Instead we recommend using the fast semihosting that comes with VisualGDB (simply enable it on the Embedded Frameworks page). It uses a memory buffer inside your chip to stream debug messages from your firmware to VisualGDB without stopping the core. This works very fast and is 100% reliable.
Hi,
This looks like a conflict between the system file provided by VisualGDB and the one that comes from STM32CubeMX. Please remove the reference to the default system init file via VisualGDB Project Properties -> Embedded Frameworks.
Thanks, we can confirm that behavior. We have contacted Symantec and submitted a false positive report. Based on our previous experience, it will take 1-2 business days for them to confirm this and add the file to the exclusion list.
Unfortunately this is a common problem with most of modern antivirus software: they basically search every executable file for known substrings that are known to occur in malware. However due to the huge size of the malware databases, a random executable file has a very chance of triggering a false positive alarm. Then we contact the antivirus vendors, get that specific file excluded and a few releases later when a few bytes are changed in the file, the problem occurs again.
To be 100% sure, please check your vgagent.exe via VirusTotal. If the checksum is 4af5f0de3cb7c87d3c4fada33372dfa020364c27a6ba9471b9db268526ab2f47, the file is authentic (currently 3 products on VirusTotal are reporting it as suspicious pending our false positive reports).
Hi,
Yes, we actually have a detailed tutorial showing how to use VisualGDB with Keil: https://visualgdb.com/tutorials/arm/keil/
Hi,
We are sorry about that. SmarTTY does not use the \??\ syntax because Visual Studio and many other tools don’t and hence the downloaded files will still be unusable.
The grayed out button should really not be related to this errors (VisualGDB/SmarTTY simply skips the paths that are too long), so please feel free to provide more details on your setup (the Toolchain.xml file and the relevant screenshots) and we will help you set it up.
