cancel
Showing results for 
Search instead for 
Did you mean: 

Strange receive errors (corrupted data) when using RX Buffer Size of 512 Bytes

robert-hartung
Associate II
Posted on August 14, 2015 at 22:39

Hello,

I wrote my own USB Library / Device Driver ( https://gitlab.ibr.cs.tu-bs.de/stm32/generic_usb_driver/ ) to support more than one endpoint for my application and to be able to have better control of data etc.

I am using my own board with an STM32F205VCT and an external High Speed USB Phy (USB3300).

I am using one OUT and two IN endpoints in addition to EP0 (IN/OUT). All use BULK transfers at the moment. The transfer itself works really good, at least most of the time!

The problem is that the data is sometimes corrupted. As far as I know USB uses CRC, so I pretend that the data is actually transfered correctly, but somehow messed up in the Software at some point. The length of the packets is read correctly, but the data seems to be corrupted.

I can read data from the correct buffer/address at the start of it. But the data is simply wrong. I cannot make any sense of the data that is red (so no byte/bit shift or something). I attached a screen showing the memory for the received 8 byte packet.

The really strange part is, that the data sometimes is correct, and after I send a different packet in between, the next packet is corrupted. Or it happens that the first packet is wrong.

After I changed the RX Fifo size from 512 bytes to 2*(512/4+1) bytes as suggested in the reference manual, it seems to better. Now I have two questions:

- Can someone clarify the use of the RX-FIFO, do I have to flush it at some point (same goes for TX FIFOs)? Why is there only one FIFO for receiving, but multiple for transmitting?

- Does someone have an idea, what could cause this error and how I might be able to debug it?

Best Regards and Thanks for any help!

Robert

#usb-device #stm32f2 #rx
5 REPLIES 5
provat
Associate II
Posted on August 14, 2015 at 23:28

I faced data corruption problem because USB clock was not configured properly.

Regards,

Provat

robert-hartung
Associate II
Posted on August 15, 2015 at 11:46

Hi Provat,

thanks for the reply. I am using the HAL_PCD library, what do you mean by configuring the USB clock?

Regards,

Robert

robert-hartung
Associate II
Posted on August 15, 2015 at 13:52

In the meantime I was able to get closer to the error. I have a GUI using libusb that sends a packet to start a measurement to the board. Afterwards I request the measurement (#0, #1, #2) from the board. After I read the data from the board, meaning receiving data, the next start-measurement-packet is corrupted. It looks like this:

after #1, get #0 0: 2 1: 0 2: 0 3: 0 4: 0 5: A2 6: 3F 7: 0 

after #2, get #0

0: 2 1: 0 2: 0 3: 0 4: 0 5: A2 6: 3F 7: 0

after #3, get #0

0: 2 1: 0 2: 0 3: 0 4: 0 5: A2 6: 3F 7: 0

after #3, get #1

0: 2 1: 1 2: 0 3: 0 4: 0 5: A3 6: C3 7: 0

after #3, get #2 0: 2 1: 2 2: 0 3: 0 4: 0 5: A3 6: 87 7:

byte 0 is 2 -> this is the packet for starting requesting a measurement.

byte 1 is equal to the last requested measurement.

bytes 3,4,5 are 0, because the measurement is a 4byte-value.

The last 2 bytes change for some unknown reason... and the last byte keeps to be 0.Is there anything I have to do after receiving data?

provat
Associate II
Posted on August 18, 2015 at 13:53

Hi Robert,

I am using STM32f429-Disco. USB library was working, how data was corrupted. Then I corrected lines below

static void SystemClock_Config(void)

 

{

 

...

 

  RCC_OscInitStruct.PLL.PLLM = 8;

 

  RCC_OscInitStruct.PLL.PLLN = 336;

 

  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

 

  RCC_OscInitStruct.PLL.PLLQ = 7;

 

...

 

}

 

 

 

  PLL_VCO = (HSE_VALUE / PLLM) * PLLN = (8000000/8)*336 =336000000

  USB OTG clock = PLL_VCO /PLLQ  = 336000000/7= 48000000 (48MHz)

 

  As per datasheet , for internal USB PHY clock should be 48HMz, and for external PHY it should be 60MHz.

 

  

Regards,

Provat

robert-hartung
Associate II
Posted on August 18, 2015 at 19:39

Hi Provat,

looks like there was only one receive buffer that caused the problems :( When using a separate receive buffer for each OUT EP, it works really well. Thanks for your help. I generate the clock directly from CubeMX, and don't have problems with it!

See my attached image!

0690X00000602ZWQAY.jpg

Regards,

Robert

________________

Attachments :

cubemx_clocktree.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htn5&d=%2Fa%2F0X0000000aWy%2FSXz70kzOTfD3LnaewvPaPpgt39LBvezfCVLbX58eN4g&asPdf=false