Forum Replies Created
-
Posts
-
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
Hi,
This looks like some kind of a symbol load problem. Please check if gdb shows your plugin in the ‘info symbols’ command output. If yes, please try adding the path to the .so file with symbols via the set solib-search path command so that gdb can load symbols for it.
Hi,
First of all, if your evaluation license runs out before you get things to work, please contact our sales and they will give you a trial extension.
Regarding the “no symbol table” error, most likely your program was built without the “-ggdb” argument and hence does not contain information required to map the disassembly back to the source code. If you are using VisualGDB Project Wizard to generate a project, it should setup everything automatically, but if you are importing a 3rd-party project, you may need to adjust its build files.
If the project is built with GNU Make, please search the Makefiles in different directories for lines defining CFLAGS (you can search for -O1, -O2 and -O3 options that define the optimization level). Once you locate them, please add -ggdb to the list of CFLAGS and rebuild the project. If this does not help, please enable verbose build logging and double-check that the -ggdb argument actually gets passed to gcc.
If you are not sure, feel free to post further details here and we will point you to the right direction.
Hi,
Thanks for clarifying this. Looks like in the latest STM32 BSP there is a small bug that prevents the oscillator speed from the wizard from being set in the project configuration.
Please locate the stm32xxx_hal_conf.h file in your project and then double-check the HSE_VALUE defined there:
#if !defined (HSE_VALUE) #define HSE_VALUE ((uint32_t)25000000U) /*!< Value of the External oscillator in Hz */ #endif /* HSE_VALUE */
Also the default LEDBlink project does not automatically configure the PLL. To do that you can generate the configuration code using the STM32Cube software, or copy it from one of other examples for your board. The typical clock configuration function looks like this:
static void SystemClock_Config(void) { RCC_ClkInitTypeDef RCC_ClkInitStruct; RCC_OscInitTypeDef RCC_OscInitStruct; /* Enable HSE Oscillator and Activate PLL with HSE as source */ RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE; RCC_OscInitStruct.HSEState = RCC_HSE_ON; RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON; RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE; RCC_OscInitStruct.PLL.PREDIV = RCC_PREDIV_DIV1; RCC_OscInitStruct.PLL.PLLMUL = RCC_PLL_MUL6; if (HAL_RCC_OscConfig(&RCC_OscInitStruct)!= HAL_OK) { Error_Handler(); } /* Select PLL as system clock source and configure the HCLK, PCLK1 clocks dividers */ RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1); RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1; RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1; if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1)!= HAL_OK) { Error_Handler(); } }
