cancel
Showing results for 
Search instead for 
Did you mean: 

VREF+, GPIOs on custom WM7 STM32WL5MOCH6TR PCBA not working

biobuilder
Associate

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.  

 

 

Capture.PNG

 

VREF+ is not connected to anything except the required bypass capacitors (0.1 uF, 4.7uF).

Capture2.PNG

 

 

The GPIOs are wired to some LEDs as shown:

Capture3.PNG

We have configured the GPIOs to push and pull.  

Capture4.PNG

 

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

1 ACCEPTED SOLUTION

Accepted Solutions

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.  

View solution in original post

2 REPLIES 2
biobuilder
Associate

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.  

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.