2025-03-08 5:23 PM - last edited on 2025-03-10 10:23 AM by STTwo-32
We recently developed a custom STM32WL5MOCH-based board. The VREF+ output is not supplying anything right now. The GPIOs seem to be floating and do not output anything.
We're using the Visual Studio Code environment and simply imported the CMake project created by CubeMX.
VDDA is measured at 3.3V. VREF+ output is measured at 0.008V to 0.03V. The GPIOs all read 0.5V to 0.6V, they do not Push / Pull and seem to be floating.
The LEDs are properly inserted and can activate as verified by external probing.
We have tried eliminating the RTOS / SubGHZ middleware to start from scratch, but the results are the same.
We have tried changing the system clock mux from HSE to the internal MSI RC, but the same results occur.
We tried changing the sys timebase source from TIM17 to SysTick, but nothing changes.
We figure there is something wrong with the software configuration, but aren't sure what.
VREF+ is not connected to anything except the required bypass capacitors (0.1 uF, 4.7uF).
The GPIOs are wired to some LEDs as shown:
We have configured the GPIOs to push and pull.
The Visual Studio Code + STLink-V3SET debugger allows us to step through the lines one by one. So we assume the code is executing on the target.
The main.c file is attached, as well as the project configuration file.
We inserted the HAL_GPIO writes inside the default task to test for blinking lights.
void StartDefaultTask(void *argument)
{
/* init code for SubGHz_Phy */
MX_SubGHz_Phy_Init();
/* USER CODE BEGIN 5 */
HAL_GPIO_WritePin(PIN_LED0_GPIO_Port, PIN_LED0_Pin, 1);
HAL_GPIO_WritePin(PIN_LED1_GPIO_Port, PIN_LED1_Pin, 0);
/* Infinite loop */
for(;;)
{
HAL_GPIO_TogglePin(PIN_LED0_GPIO_Port, PIN_LED0_Pin);
HAL_GPIO_TogglePin(PIN_LED1_GPIO_Port, PIN_LED1_Pin);
//HAL_GPIO_WritePin(PIN_LED0_GPIO_Port, PIN_LED0_Pin, 1);
//HAL_GPIO_WritePin(PIN_LED1_GPIO_Port, PIN_LED1_Pin, 0);
osDelay(250);
}
/* USER CODE END 5 */
}
We have tried two different boards now with the same results. What are we missing here?
Thanks,
Damon
Solved! Go to Solution.
2025-03-10 9:06 AM
The end solution was to uninstall the "ST32 VS Code Extension" from ST and replace it with the "STM32-for-vscode" extension from Bureau Moeilijke Dingen. We generated a new Makefile project with STM32CubeMX. We then ran the setup script and installed the tools and environment variables to debug in Visual Studio Code. We set the debugger to STLink-V2-1, which seemed to connect with our STLink-V3SET debugger device. Now we will continue programming and debugging in the visual studio code environment. Unfortunately, the STM32 VS Code Extension published by ST is currently not working properly, at least not for us.
2025-03-10 8:28 AM - edited 2025-03-10 8:30 AM
We discovered that when configuring the project for CubeIDE, the system does work as intended, the GPIOs activate as needed. What this means is that CubeMX does not properly configure the CMake project for compilation in Visual Studio Code. So there is a bug in the STM32 Visual Studio Code extension or CubeMX which breaks the execution.
In summary, the STM32 CubeMX code generator when combined with the STM32 Visual Studio Code extension does not produce reliable code or compilation. We would like to see if there is anything that can be done to operate in the visual studio environment over the Cube MX IDE.
2025-03-10 9:06 AM
The end solution was to uninstall the "ST32 VS Code Extension" from ST and replace it with the "STM32-for-vscode" extension from Bureau Moeilijke Dingen. We generated a new Makefile project with STM32CubeMX. We then ran the setup script and installed the tools and environment variables to debug in Visual Studio Code. We set the debugger to STLink-V2-1, which seemed to connect with our STLink-V3SET debugger device. Now we will continue programming and debugging in the visual studio code environment. Unfortunately, the STM32 VS Code Extension published by ST is currently not working properly, at least not for us.