USB problems are making me savage!!!

[ashley23]

Posted on August 20, 2010 at 01:56

USB problems are making me savage!!!

#file-system-on-on-chip-flash-memory-in-stm32f103

[Nickname12657_O]

Posted on May 17, 2011 at 14:03

Dear duncan,

what is your exact STM32F1xx device ?   The behavior on ''INs''  is not the same between Connectivity 10/7 devices and others.  For the first we need first to write data on FIFO then waiting till the host will send an IN token, whereas for our STM32F102, 103 we have to validate data after writing to the PMA so they can be sent out to the host. 

Cheers,

STOne-32.

[ashley23]

Posted on May 17, 2011 at 14:03

Yeah, that USB/CAN sharing RAM and port pins is stupid!  I have ordered some connectivity devices...

I am assuming you are talking about interrupt IN endpoints where the host keeps checking for ready tx data?

I am using the ST library but having some trouble with the tx data.  It seems you need to seed some data to get the tx going, then use the endpoint callback to keep the buffers full.

I am trying to make a USB to CAN device so I am struggling to determine the best way to transfer data to/from the PC with minimum delay and no loss of data...

[chikos332]

Posted on May 17, 2011 at 14:03

Hi,

- If you are using the STM32F1x5xxx or STM32F1x7xxx devices, no chance, you can't use both USB and CAN (they have shared RAM).

- For the IN endpoints, the Host is always sending IN requests to the device with fixed intervals (you can configure the interval with the endpoint descriptor). If the device has some ready data, it sends them, otherwise it only NAKs the the requests (In this case the host knows that the device has no data to send).

So you have to know that you just have to write data in the IN endpoint FIFO or Memory whenever they are ready.

By the way, are you using the ST USB library or developing your own code?

[ashley23]

Posted on May 17, 2011 at 14:03

OK... So, now I am up and running.  What you said did not click until I read it the fifth time!!!   I was expecting my IN endpoint callback to be hit when the PC called readpipe(), where I would then load the tx data into the buffer...  But it turns out assumption was a bad idea.

So, I changed it so that it copies the OUT endpoint data into the IN buffer during the OUT endpoint callback (loopback effect) and it started working perfectly.

Firstly, I am so f#*king happy right now.  I never usually get stuck like this and have now had a taste of how it feels!!!  Secondly, where in the literature would I have found this ?  I am sure I have read it by now but didn't realise.

I have a few other questions too:

  1 - So, when do endpoint IN callbacks get hit?  Interrupt in pipes?

  2 - What is the best method of sending tx data?  Does the embedded application just chuck some bytes into the IN buffer as it feels then hope that the PC decides to call readpipe?  

My intention is to make a USB to CAN adapter so I want to send CAN frames as they arrive and transmit them from the PC...

I also recently found out the above mentioned device does not allow use of its USB and CAN peripherals at the same time which was a real disappointment...

Thanks heaps for your help.... 

   

[epassoni950]

Posted on May 17, 2011 at 14:03

Hello,

Message from chikos is wrong. With connectivity line devices STM32F105xxx or STM32F107xxx you *can* use USB and CAN both at the same time. It is for performance line devices STM32F103xxx that you can't use USB and CAN both at the same time because of shared Ram.

For IN endpoint, just put your data in IN endpoint Fifo (USB Ram) when you have data to send to PC host. If IN endpoint is busy, just wait until it is free. A better method, is to manage a buffer between your application and USB IN endpoint. When you have data to send to host PC, store data in this buffer. During an IN endpoint interrupt, refill IN endpoint Fifo (USB Ram) with next data in your buffer. You can send data to host PC even if host PC did not send any data to device. You can note that this method is very similar to send byte to a PC with a Uart except for size : Uart transmit register is one byte, IN endpoint Fifo is larger (often 64 bytes).

Regards

Eric

[tsuneo]

Posted on May 17, 2011 at 14:03

Hi duncan,

> Everyone keeps saying if I write to a IN endpoint buffer, the data will be sent to the PC, even if the PC doesn't ask for it (like using a UART),  But, it just doesn't seem to work that way.

The data on the IN endpoint is sent to host just when the host issues IN transaction to the IN endpoint. When this transaction completes (ie. host returns ACK), the endpoint interrupt occurs, and endpoint IN callback gets hit. 

You didn't specify the USB class of the device. It's the reason why the answer from everyone differs from your experience.

HID class driver on PC puts IN transactions repeatedly to the device interrupt IN endpoint, regardless your PC application reads it or not. CDC (virtual COM port) class driver works like so, for its bulk IN and interrupt IN endpoints. Everyone refers to this class driver behavior.

But when you are working on a generic device driver, like WinUSB, IN transaction is put just when your PC application calls WinUSB_ReadPipe().

Tsuneo

[Nickname12657_O]

Posted on May 17, 2011 at 14:03

Hi,

I confirm what was said by Eric is correct, you can check out our FAQ on the subject :

http://www.st.com/stonline/faq/faqview.php?ids=1228

To build an''USB to CAN bridge''  ( CAN transfers are up to 1Mbits) you need to use our Connectivity devices : STM32F105/7.

Cheers,

STOne-32.

[ashley23]

Posted on May 17, 2011 at 14:03

Yeah, as I said above I have already ordered some connectivity line devices...

I am still stuffed on the in endpoint thing.  Everyone keeps saying if I write to a IN endpoint buffer, the data will be sent to the PC, even if the PC doesn't ask for it (like using a UART),  But, it just doesn't seem to work that way.  If I write some data to the endpoint buffer (in application code), the endpoint callback does not seem to be hit until after the PC has done a read and the buffer needs more data.

I know I am missing something but I just dont know what!!!

[Nickname12657_O]

Posted on May 17, 2011 at 14:03

Good progress

by the way, Here is a snippet code on how using WinUSB at

http://www.lvr.com/winusb.htm

using C# and Visual 2008 &

http://www.microsoft.com/whdc/device/connect/WinUsb_HowTo.mspx

[ashley23]

Posted on May 17, 2011 at 14:03

''

The data on the IN endpoint is sent to host just when the host issues IN transaction to the IN endpoint. When this transaction completes (ie. host returns ACK), the endpoint interrupt occurs, and endpoint IN callback gets hit.

You didn't specify the USB class of the device. It's the reason why the answer from everyone differs from your experience.

HID class driver on PC puts IN transactions repeatedly to the device interrupt IN endpoint, regardless your PC application reads it or not. CDC (virtual COM port) class driver works like so, for its bulk IN and interrupt IN endpoints. Everyone refers to this class driver behavior.

But when you are working on a generic device driver, like WinUSB, IN transaction is put just when your PC application calls WinUSB_ReadPipe().''

Thanks for that...  I guess i just assumed that when I said I was using WinUSB it meant I was using a generic (0xFF) class device.  I will be more specific next time.  So can someone please confirm that this is the behavior I should expect to see:

Micro has data ready first:

1. Device application code (not in callback) writes data to the USB buffer 0.
2. Some time later the PC calls ReadPipe() with a specific number of bytes.
3. The device sends buffer 0 data.
4. The callback happens where more data is loaded into the buffer 1.
5. Steps 3 and 4 repeat until the PC gets enough bytes alternating between buffer 0 and 1.

PC Calls ReadPipe first:

1. PC calls ReadPipe() which blocks waiting for the specified number of bytes.
2. Some time later device application code writes the first block of data to the buffer 0.
3. The data is sent.
4. The IN callback happens where more data is loaded into the buffer 1.
5. Steps 3 and 4 repeat unitl the PC gets enough bytes alternating between buffer 0 and 1.

All I am trying to do now is work out a reliable way of getting all my data to the PC in a timely manner with minimal delays.  Not sure if I said above but I am making a USB-CAN adapter.  So far I have a double buffered IN and OUT endpoint and can achieve the data rates I want.  Now I just need to tidy it up and get it working ''proper''.