cancel
Showing results for 
Search instead for 
Did you mean: 

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

xhan.11
Associate II

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

1 ACCEPTED SOLUTION

Accepted Solutions
xhan.11
Associate II

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.

View solution in original post

4 REPLIES 4
xhan.11
Associate II

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
Lead III

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.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
xhan.11
Associate II

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.

Hello @xhan.1​ ,

Glad to know the issue has been solved.

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

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen