STM32F103VBTx GPIOC pin3 Pulling up first and then down will result in failure to receive CDC data within 100ms,Probabilistic

[xhan.11]

Hi​：

STM32F103VBTx 

STM32CubeMX_v5-3-0

The basic code is generated by cube.

​

There are the following changes:

​

static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)

{

  /* USER CODE BEGIN 6 */

CDC_rx_len += *Len;//pinjie

    USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &UserRxBufferFS[CDC_rx_len]);

USBD_CDC_ReceivePacket(&hUsbDeviceFS);

   return (USBD_OK);

  /* USER CODE END 6 */

}

​

int main(void)

{

.....

......

while (1)

    { 

if (CDC_rx_len)

        {

​ ......

.......

switch (UserRxBufferFS[i + 1])

                    {

​ case 0xAC: //RF0 contrl

                    temp8 = UserRxBufferFS[i + 1];

                    GPIOC->BSRR = ((~temp8 & 0X3F) << 16) | (temp8 & 0X3F);

                    temp8 = ((GPIOE->IDR & 0xc0) >> 2) | ((GPIOD->IDR & 0xc0) >> 4) | ((GPIOC->IDR & 0xc0) >> 6);

                    UserTxBufferFS[0] = temp8;

                    USB_send(UserTxBufferFS, 1) ;

                    i = i + 4;

                    spi_i2c_mode = 0xff;

                    break;

......

}

.....

i++;

.......

if (i >= CDC_rx_len)

            {

                USBD_CDC_SetRxBuffer(&hUsbDeviceFS, UserRxBufferFS);

                USBD_CDC_ReceivePacket(&hUsbDeviceFS);  

                CDC_rx_len = 0;

                i = 0;

            }

}

}

​

​

The purpose of this change is to put the unfinished data processed by STM32 behind the buffer.This part of the change does not affect, and restoring the code will also appear.

​

After testing, it is found that if gpioc PIN3 is pulled up first and then down, there is a probability that it will fail to receive data within 100ms. Once every dozens of times. If gpioc PIN3 is always at low level, this phenomenon does not exist.Other pins do not have this phenomenon.

thanks

​

​

​

​

[xhan.11]

update

STM32 link a TPL7407​（30-V, 7-ch NMOS array low-side driver

）control 87106B(24V RF switch）

This phenomenon will not occur when I do not connect the RF switch or fully open the RF switch

​

[gbm]

Standard response to USB device related questions: do NOT call any USB routines from main; they should be called only from an interrupt routine of the same priority as the USB interrupt.

[xhan.11]

It has been solved. The reason is that the crosstalk to the ground is too large at the moment when the RF switch is turned off.

[Imen.D]

Hello @xhan.1​ ,

Glad to know the issue has been solved.

Please allow me to close this thread by marking select Best answer.

Imen