STM32F407 Strange SerialUsbDriver behavior

[kioskpayprogrammers]

attachments:
1)usb_serial.zip contains configuration of serial_usb system
2)SerialUsbTest.zip contains test visual studio 2010 C# project

SerialUsbTest\bin\Debug\SerialUsbTest.exe - test aplication

approximately device code

Code: Select all


void USB_init_serial(void)
{
   sduObjectInit(&usb_serial);
   sduStart(&usb_serial, &usb_serial_config);

   usbDisconnectBus(usb_serial_config.usbp);
   chThdSleepMilliseconds(1000);
   usbStart(usb_serial_config.usbp, &usb_config);
   usbConnectBus(usb_serial_config.usbp);
}

void debug_buffer(BaseSequentialStream* debugStream, uint8_t* data, uint16_t length)
{
   for (int i = 0; i < length; i++)
   {
      chprintf(debugStream, "%02x", data[i]);
      if (i < length - 1)
         chprintf(debugStream, " ");
   }
}

static uint8_t temp_buffer[2048] = {};

int main(void)
{
  halInit();
  chSysInit();
  sdStart(&SD3, &sd_cfg);

  USB_init_serial();
  chThdSleepMilliseconds(3000);

   msg_t c;
   uint16_t index = 0;
   

   while(true)
   {
      while ( (c = chnGetTimeout(&usb_serial, MS2ST(50))) != Q_TIMEOUT )
      {
         temp_buffer[index++] = (uint8_t)c;
      }

      if (index > 0)
      {
         debug_buffer((BaseSequentialStream*)&SD3, temp_buffer, index);
         chnPutTimeout(&usb_serial, '@', TIME_INFINITE);
      }

      index = 0;
   }

}


[Giovanni]

Hi,

I committed a change in repository (trunk), could you check if it does fix the problem?

What I fixed is the check for transaction terminated by short/zero packets, it failed to detect transactions terminated by zero packets and this would explain why you had problems with writes that are a multiple of packet size.

If you can confirm correct behavior then this will go in next release.

Giovanni

[Giovanni]

Nevermind, the change is not effective, for some reason the driver is not terminating OUT transaction when the received size is smaller than the specified transaction size AND the last packet is equal to the max packet.

It could be:
1) The host does not send a zero packet.
2) The driver fails to detect the zero packet for some reason.

I am working hoping that 2 is true, if it is 1 then there is nothing I could do. I reverted the previous change.

Giovanni

[Giovanni]

I found this article (see last section):

https://msdn.microsoft.com/en-us/librar ... 38112.aspx

Apparently the host does not send zero sized packets, it is responsibility of the "client driver" (upper layers) to insert those zero packets as appropriate.

This means that the device driver on the STM32 has no mean to detect short transfers aligned to packet size by itself unless the host application sends an explicit "wakeup".

I guess the same is true for Linux hosts.

This could be confirmed using an real USB analyzer but I don't have one right now.

Giovanni

[baoshi]

I can confirm this behavior using Saleae Logic tapping on USB wires. I'm using a STM32F303.
When I'm sending 64 bytes, I see one 64 bytes packet and one 1 byte packet.
When I'm sending 64 bytes via CDC, only one OUT packet is captured with length 64 bytes, no zero length packet follows.

I see no easy fix unless I define SERIAL_USB_BUFFERS_SIZE to 64, this causes RX callback to be called for every packets or 64 bytes or below.

The ST USB stack does not suffer this issue because they do not buffer up packets. RX callback is called for every received packets no matter what length it is.

[Giovanni]

Hi,

Without a zero size packet there is no way for the driver to terminate the transaction and generate an event, reducing buffers is the only way I believe... of course there is a performance impact.

Giovanni