cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE Debugger operation seems to override a COM Port

OIp.1
Associate III

Hi. I am attempting to get a basic USB_FS to communicate between my STM32 Board (STM32756-EVAL) and my PC, through PuTTY. The following are the configs on my PuTTY connection.

0693W00000Y9LmUQAV.pngAnd the following is my code in main.c:

#include "main.h"
#include "i2c.h"
#include "ltdc.h"
#include "quadspi.h"
#include "sai.h"
#include "spdifrx.h"
#include "usb_device.h"
#include "gpio.h"
#include "fmc.h"
 
uint8_t buffer[64];
 
void SystemClock_Config(void);
void PeriphCommonClock_Config(void);
 
int main(void){
  HAL_Init();
 
  SystemClock_Config();
 
  PeriphCommonClock_Config();
 
  MX_GPIO_Init();
  MX_FMC_Init();
  MX_I2C1_Init();
  MX_LTDC_Init();
  MX_QUADSPI_Init();
  MX_SAI1_Init();
  MX_SAI2_Init();
  MX_SPDIFRX_Init();
  MX_USB_DEVICE_Init();
 
  while (1)  {
	  HAL_GPIO_TogglePin(GPIOF, GPIO_PIN_10);
	  uint8_t message[] = "Help! I'm stuck in the CCCFP machine!\r\n";
	  CDC_Transmit_FS(message, sizeof(message));
	  HAL_Delay (1000);
  }
}

My code in USB_DEVICE\App\usbd_cdc_if.c is the following:

extern uint8_t buffer[64];
 
static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len){
  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
  USBD_CDC_ReceivePacket(&hUsbDeviceFS);
 
  memset (buffer, '\0', 64);  // clear the buffer
  uint8_t len = (uint8_t)*Len;
  memcpy(buffer, Buf, len);  // copy the data to the buffer
  memset(Buf, '\0', len);   // clear the Buf also
 
  return (USBD_OK);
}
 
uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len){
  uint8_t result = USBD_OK;
  USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDeviceFS.pClassData;
  if (hcdc->TxState != 0){
    return USBD_BUSY;
  }
  USBD_CDC_SetTxBuffer(&hUsbDeviceFS, Buf, Len);
  result = USBD_CDC_TransmitPacket(&hUsbDeviceFS);
  return result;
}

Whenever I engage the Debugger, my device manager immediately fails to detect COM8 (the STM32 USB_FS port). I am unsure why that is. The error message on PuTTY:

0693W00000Y9Lw5QAF.pngThe original Device Manager before the debugger becomes active:

0693W00000Y9LxXQAV.pngAfter the debugger becomes active:

0693W00000Y9LxcQAF.pngI am not using COM7 because I seem only able to receive USB messages from COM8 and COM7 is connected to the debugger.

I am powering my board with the CN17 external power port, and also connected to CN13 micro-USB, as well as CN21 USB-B for the debugger.

Please let me know if more details or clarity is required.

5 REPLIES 5
Pavel A.
Evangelist III

> Whenever I engage the Debugger, my device manager immediately fails to detect COM8 (the STM32 USB_FS port).

USB device operation requires real-time response. Debugger is intrusive, it causes the device to lose connection with host.

Thank you. But what about Virtual COM Port 7, which is the COM Port for the debugger? Is that Port still active because the debugger is still sending info between the board and the PC at real time, while the board itself isn't running at real time?

OIp.1
Associate III

Also, is there a way to debug the device while using USB_FS as a critical element of my code's communication. I am testing an echo for USB_FS, hence I need USB_FS to work during the debug session.

Also, is there a way to debug the device while using USB_FS as a critical element of my code's communication. I am testing an echo for USB_FS, hence I need USB_FS to work during the debug session.

Javier1
Principal

that COM7 port youre seeing is the stlink's com port, stlink outputs all received UART1 from the tarjet mcu (depends of the board) data trough that COM7 port.

we dont need to firmware by ourselves, lets talk