Forum Replies Created
-
Posts
-
Hi,
Unfortunately this is not possible directly. Selecting one of the build subsystems simply tells VisualGDB how to build the project, but it does not automatically add any special preprocessor macros to the project settings. So the only way to detect Qt out-of-the-box would be to check for macros that QMake itself defines.
Defining a macro like QT_PRESENCE via VisualGDB Project Settings is also a good workaround.
Hi,
Good to know it works.
The ‘custom’ build system is used for projects where VisualGDB does not control the Makefile structure and cannot do precisely aimed edits to it. This is always the case when you import an external project (as the Makefile was not generated by VisualGDB). The only practical difference is that you would need to synchronize IntelliSense settings manually and edit the Makefiles directly instead of the VisualGDB GUI.
When you switch to the regular GNU Make subsystem, VisualGDB regenerates the Makefile based on its own template and will know how to edit it based on the settings from GUI. Although this is easier to handle, it will replace any custom steps present in the original Makefile, so VisualGDB does not to this unless explicitly requested.
Hi,
It is hard to tell what is causing this without knowing more about your project structure. Looks like VisualGDB managed to upload 1 new file, but when Make was launched remotely, it did not find any changes. This could happen if your Makefile rules don’t properly reference the file you uploaded or if your upload settings exclude some files vital for building.
We would recommend enabling verbose output via Tools->Options->VisualGDB, checking which source file gets uploaded and then double-checking the Make rules to see that this file is listed as a dependency.
Hi,
You can do that manually by simply creating a ‘static library’ project, moving the necessary files there and referencing that project from other projects. However you may run into problems as different device types have slightly different sets of peripherals and hence the HAL library needs to be recompiled for each one separately.
Hi,
Sorry about the confusion. You can configure VisualGDB to import the .xml files via Tools->Options->VisualGDB->General->Files->Source extensions to import.
Regarding the copying, please double-check that the xml file is located inside the directory that is configured for copying. You can enable the verbose mode (Tools->Options->VisualGDB->General->Output->Enable Verbose Output) to see detailed information on the files that get uploaded. If you see other files from that directory, but not the XML file, please check your file transfer masks. If you don’t see any file from that directory, please double-check the source directory.
Hi,
The Linux kernel is unfortunately not as well-designed in terms of debugging as the Windows one, so unless you are using JTAG or VMWare that runs on top of the kernel, random hanging could happen. Our best advice would be to try disabling all CPU cores except #0. This should reduce the chance of deadlocks in the kernel.
Also if this is possible, we would advise getting a special machine with a JTAG connection. Although this is slower than debugging over serial port, this will be 100% reliable as the debugging logic will run on top of the kernel without sharing any resources with it.
Hi,
VisualGDB actually offers several mechanisms that simplify using of the same project by different users (e.g. toolchain and BSP relocation). We even have a detailed tutorial on that: http://visualgdb.com/tutorials/arm/multiuser/
Regarding the toy/serious tool, based on our experience, one could roughly split software developers into those who prefer command line tools and those who prefer complex GUI. Both approaches have pros and cons and it’s ultimately a question of preference. Visual Studio is designed to appeal mainly to those who prefer GUI, so it is understandable that some parts of it could appear counter-intuitive if you are more used to command line tools. With VisualGDB we try to appeal to both types of developers by keeping all the internal configuration data in easily readable and modifiable XML files that could be easily customized via scripts if you prefer that approach.
We are also open to suggestions on improving our products even more, so feel free to share your ideas about the things that could be made more convenient.
Hi,
You could try checking for QT_CORE_LIB, but if you want a 100% accurate answer, we would recommend asking on the Qt forums.
Hi,
Qt Designer is very basic (e.g. it won’t show your custom widgets properly unless specifically configured), so you can use any one that works. The one from the Win32 Qt build should suffice.
Hi,
ESP32 has 3 different watchdogs that could be restarting the CPU once it is stopped and we experienced similar behavior before we modified the ESP32 OpenOCD to explicitly disable them:
xtensa_write_hwreg(target, 0x3FF5F064, 0x50d83aa1); //TIMG1 WDT xtensa_write_hwreg(target, 0x3FF5F048, 0); xtensa_write_hwreg(target, 0x3FF60064, 0x50d83aa1); //TIMG2 WDT xtensa_write_hwreg(target, 0x3FF60048, 0); xtensa_write_hwreg(target, 0x3ff480a4, 0x50d83aa1); //RTC WDT xtensa_write_hwreg(target, 0x3ff4808c, 0);
Our best guess is that in your case this mechanism does not work. Unfortunately the ESP32 tools are currently not very reliable and do not provide good troubleshooting mechanisms, so the only advice we could give is to do some black box experiments to understand what triggers the problem.
Hi,
No problem. This is somewhat counter-intuitive and we will probably add a warning for this in one of the later releases.
Hi,
Yes, please add *.xml to the “copied file masks” under VisualGDB Project Properties -> Project Settings.
Hi,
The VCP_write() function is provided by us and it’s based on the original sample from ST and it indeed contains a bug with HS instead of FS. The correct version should look like this:
#ifdef USE_USB_HS enum { kMaxOutPacketSize = CDC_DATA_HS_OUT_PACKET_SIZE }; #else enum { kMaxOutPacketSize = CDC_DATA_FS_OUT_PACKET_SIZE }; #endif int VCP_write(const void *pBuffer, int size) { if (size > kMaxOutPacketSize) { int offset; int done = 0; for (offset = 0; offset < size; offset += done) { int todo = MIN(kMaxOutPacketSize, size - offset); done = VCP_write(((char *)pBuffer) + offset, todo); if (done != todo) return offset + done; } return size; } USBD_CDC_HandleTypeDef *pCDC = (USBD_CDC_HandleTypeDef *)USBD_Device.pClassData; while (pCDC->TxState) {} //Wait for previous transfer USBD_CDC_SetTxBuffer(&USBD_Device, (uint8_t *)pBuffer, size); if (USBD_CDC_TransmitPacket(&USBD_Device) != USBD_OK) return 0; while (pCDC->TxState) {} //Wait until transfer is done return size; }We have updated this internally and will include the fix in the next release of the BSP. Regarding packets larger than CDC_DATA_FS_OUT_PACKET_SIZE, they do sometimes work, but may not be fully supported by the hardware and hence may cause strange effects, so we would not recommend using them.
Hi,
It’s hard to say what is causing this without more details. Normally when VisualGDB runs the ‘mon reset init’ command (unless you have disabled chip reset via Debug Settings), the stack pointer should be reset based on the contents of the interrupt table.
Please try running the ‘mon reset init’ command manually and check if the output shows the correct sp value:
xPSR: 0x01000000 pc: 0x080026bc msp: 0x20020000
If yes, please check that the OpenOCD window contains similar text at the beginning of the log:
adapter speed: 1800 kHz stm32f4x.cpu: target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000
