STM32F10x HAL USB debug issue

[Lenoe]

Posted on October 30, 2016 at 14:04

Hello everyone!

I tried to create a CDC to PC interchange project in Cube on STM32F103C8T6 (as you can see in attached file) and I have some kind of trouble — debug doesn't works properly. During debug my sample project any VCP terminal that I have shows that device doesn't works (any data can not be received or transmitted from device), but debug still continues normally. So, without debug the following code works fine:

static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len)
{
/* USER CODE BEGIN 6 */
// USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
// USBD_CDC_ReceivePacket(&hUsbDeviceFS);
// return (USBD_OK);
for (int i = 0; i < *Len; i++)
UserTxBufferFS[i] = UserRxBufferFS[i];
USBD_CDC_SetTxBuffer(&hUsbDeviceFS, &UserTxBufferFS[0], *Len);
USBD_CDC_TransmitPacket(&hUsbDeviceFS);
USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &UserRxBufferFS[0]);
USBD_CDC_ReceivePacket(&hUsbDeviceFS); 
return (USBD_OK);
/* USER CODE END 6 */ 
}

uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
{
uint8_t result = USBD_OK;
/* USER CODE BEGIN 7 */ 
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);
/* USER CODE END 7 */ 
return result;
}

I can receive any transmitted data from device. Is anyone know how to solve this?

[Davis Rollman]

Posted on January 05, 2018 at 00:13

Hi, I'm having a similar issue. I have the ST VCP driver installed, and I use PuTTY in windows 10, the newest update. I use System Workbench. If I 'run' or 'debug' on my device (STM32F4 Discovery board) then I cannot connect to it through putty unless I unplug and replug the usb cable, so after that, debugging is lost... but I can connect to the serial port fine. Debugging works absolutely fine, but just can't connect to the CDC device. Putty says: 'Unable to open connection to COM2: unable to configure serial port'. Could this be a windows issue? I've attached my code.

________________ Attachments : STM32F4_DISC_Testing.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyDy&d=%2Fa%2F0X0000000b4n%2FDPioHQaVd2XdQpa9NPEB77Z8hGh43MS8461ciRSAKEU&asPdf=false

[Ben K]

Posted on January 05, 2018 at 12:00

The host side USB drivers usually have a timeout on device setup requests (such as getting descriptors, or setting the CDC line coding). Debugging halts the execution of the code, therefore if you have a breakpoint which blocks the EP0 transfer path during the establishment of the USB and VCP connection you will likely get a VCP connection problem. My recommendation is to enable breakpoints only after connected to VCP.

[Davis Rollman]

Posted on January 05, 2018 at 19:49

Thanks, but after this I still have the same error. I removed all breakpoints and removed the initial default breakpoint. Also, I've attached mystartup settings in my debug configuration.

In addition, when I debug this configuration here is the console output:

Open On-Chip Debugger 0.0-dev-00005-g4030e1c-dirty (2017-10-25-10:55)

Licensed under GNU GPL v2 For bug reports, read

/external-link.jspa?url=http%3A%2F%2Fopenocd.org%2Fdoc%2Fdoxygen%2Fbugs.html

srst_only separate srst_nogate srst_open_drain connect_assert_srst Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter_nsrst_delay: 100 adapter speed: 1800 kHz Info : tcl server disabled Info : telnet server disabled Info : clock speed 1800 kHz Info : STLINK v2 JTAG v29 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : vid/pid are not identical: 0x0483/0x374B 0x0483/0x3748 Info : using stlink api v2 Info : Target voltage: 2.885933 Info : Stlink adapter speed set to 1800 kHz Info : STM32F407VGTx.cpu: hardware has 6 breakpoints, 4 watchpoints Info : accepting 'gdb' connection on tcp/3333 Info : Stlink adapter speed set to 1800 kHz adapter speed: 1800 kHz STM32F407VGTx.cpu: target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08005e3c msp: 0x20020000 configuring PLL Info : Stlink adapter speed set to 4000 kHz adapter speed: 4000 kHz Info : device id = 0x10016413 Info : flash size = 1024kbytes Info : Stlink adapter speed set to 1800 kHz adapter speed: 1800 kHz STM32F407VGTx.cpu: target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08005e3c msp: 0x20020000 Info : Stlink adapter speed set to 1800 kHz adapter speed: 1800 kHz STM32F407VGTx.cpu: target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08005e3c msp: 0x20020000 configuring PLL Info : Stlink adapter speed set to 4000 kHz adapter speed: 4000 kHz STM32F407VGTx.cpu: target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x20000046 msp: 0x20020000 Info : Stlink adapter speed set to 1800 kHz adapter speed: 1800 kHz STM32F407VGTx.cpu: target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x08005e3c msp: 0x20020000

Do you know why this output is saying ''target halted due to breakpoint'' even though I have no more breakpoints? This can't be some sort of st-link breakpoint, because it says the target is

STM32F407VGTx.cpu.

Edit: I'd also like to point out that when I build then just run, not debug, the st link programs the processor fine and then the program runs fine, and I can blink an LED on a timer fine, but I still cannot connect via putty. This leads me to believe there is some kind of driver issue with the st vcp driver. Has anyone else had this issue?

[Ben K]

Posted on January 06, 2018 at 17:23

The target is halted due to startup reset, which should be fine. I prefer not to enable 'Reset and Delay', 'Halt' nor 'Resume', but I'm not entirely sure of their relevance.

In your code I noticed the lack of SET_LINE_CODING and GET_LINE_CODING implementation, I would try it with the original template code, maybe this causes the VCP connection issue:

 case CDC_SET_LINE_CODING:
 linecoding.bitrate = (uint32_t)(pbuf[0] | (pbuf[1] << 8) |\
 (pbuf[2] << 16) | (pbuf[3] << 24));
 linecoding.format = pbuf[4];
 linecoding.paritytype = pbuf[5];
 linecoding.datatype = pbuf[6];
 
 /* Add your code here */
 break;
 case CDC_GET_LINE_CODING:
 pbuf[0] = (uint8_t)(linecoding.bitrate);
 pbuf[1] = (uint8_t)(linecoding.bitrate >> 8);
 pbuf[2] = (uint8_t)(linecoding.bitrate >> 16);
 pbuf[3] = (uint8_t)(linecoding.bitrate >> 24);
 pbuf[4] = linecoding.format;
 pbuf[5] = linecoding.paritytype;
 pbuf[6] = linecoding.datatype; 
 
 /* Add your code here */
 break;�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

[NShut]

I have same bug on Linux and OSX. Last CubeMX, initial project. Eclipse + OpenOCD

CubeMX creators use debugging ?