USB FS Device Driver question

[hpipon957]

Posted on February 14, 2012 at 02:38

Hi All

I am wondering whether anyone has worked in detail with the USB FS device and can share some insight into it? What I have been doing for some days is working on a driver specifically for the device mode and have (after some fighting with the controller) managed to get functionality in MSD, HID and CDC modes but not without having to do some unexpected things and solve some problems due to operations which are not explained in much detail in the user's manual (working on F4 device but I assume identical for F1, F2). To start the ball rolling - if anyone is interested - I have four questions (observation topics): 1) I was expecting that data could be prepared in the IN FIFOs and transmission started by simply activating the endpoint (sort of as suggested in the user's manual). Since all attempts and experiments to do this on the control endpoint 0 failed (it would send either zero date or maybe just 1 byte of the data) I finally settled for the (strange) method used in the ST library of activating the endpoint with details of the data size (before writing the data) and actually performing the data write via a TX FIFO empty interrupt. Although this interrupt fires immediately copying the FIFO content like this works reliably. Attempt to wait for some flag (clock domain synchronisation?) didn't work and also inserting delays instead of the interrupt method was also not very sucessful - if a (massive) 50us delay was inserted it then worked reliably but smallish delays of several us didn't (usually it would send just fragments of the data copied into the FIFO). Rather strange - anyone explain? Note that the other endpoints also didn't allow the FIFO content to be set before enabling the endpoint transmission but they do allow the FIFO data to be immediately added to the FIFO without the need to do it based on the Tx FIFO empty interrupt - so there is something a little different there (?). Final note - between a control endpoint SETUP token and sending an IN there is usually one NAK. (Same effect from ST library demos). Handling a SETUP frame requires four interrupts (one notifying of SETUP RX, one notifying SETUP OK, followed by an OUT on endpoint 0 and finally the IN endpoint FIFO empty - the last three interrupts are very fast so that they are handled without exiting the original ISR). Even though the processor is operating at 168MHz I am wondering why the USB controller still sends one NAK and so delays the IN data, other USB controllers that I have used have no problems in answering the SETUP with immediate IN data without a NAKed frame inbetween...(?) 2) I read the descriptions of the setup of the USB FIFO buffer area (several times) but can't really work out what is the best thing to do. For the moment I have simply set 64 words of the 1.25kByte memory for each of the endpoints. The idea is that the area can be divided up between the endpoint to best suit the endpoint use by the application. Also there is detail of the control endpoint 1 requiring 10 words for operation, but all attempts to optimise its size (eg. using just 8 bytes endpoint length and setting its FIFO size to a smallish value of say 40 bytes stopped it working at all (either it didn't recognise SETUPs any more or its transmission would be corrupted in some way). In fact the configuration details don't make a lot of sense and changing things tends to make the basic operation fail so I am wondering whether anyone has done any work with optimising the FIFO assignment sizes with success? 3) I have found that between each IN and each OUT token handling there is a 'spurious' USB interrupt. That is, the USB ISR is called without any interrupt flags set. The ISR checks all possible USB interrupt causes, finds nothing and so returns. There are no side effects of this apart from the unnecessary interrupt call and I also saw that the ST library has a spurious interrupt check in its USB ISR which also just returns. I am wondering whether anyone else noticed this and maybe found a way to quieten it? 4) Usually it is possible to work with dual-buffered IN data. Also the FIFO depth available and the user's manual description suggests that this is possible (maybe even up to quad-buffering). The effect is to reduce the processor's reaction requirements when sending blocks of data so that the bandwith can be maximised. I had the feeling that the ST library driver doesn't attempt to make use of this (if I didn't misunderstand) and also I am not sure what would be the way to go about using it (especially due to the difficulty of not being able to set data to the FIFO before starting its operation). This is probably the final phase of optimising throughput with minimum processor overhead and will be the next work to be started. If any one has some experience and tips before the investigations start it would certaily be very useful! Thanks Regards Mark

http://www.utasker.com/

#usb-device-driver-utasker

[ababo]

Posted on January 06, 2014 at 13:52

Hi mjbcswitzerland,

About your point 1, I am having the same problem!After putting the data to transmit into the endpoint buffer, starts an interrupt storm and just stops after the host polls the IN endpoint!The problem is that I have some things to do during that time, but the MCU gets stuck!Did you find any solution for this issue??Thanks :)