ChibiOS Free Embedded RTOS

Interesting...
So I increased the TX Fifo in usb_lld_init_endpoint to 256 bytes and was able to push 4k packets à 64 bytes equalling 0.25MB/s which is already much better.
I wasn't able to decrease the RX fifo below 256 and even at that value, increasing the TX to 512 didn't really work.
As I understand, USB up to 2.0 is half-duplex? Is it so, that to achieve maximum bandwidth you need to fill the fifo with 1 frame worth of data? So to achieve maximum bandwidth in both directions you'd need to dynamically adjust fifo sizes depending on if you need TX or RX bandwidth? And even allocate that space to the EP that needs it?
Still investigating...

*edit* I'm not sure, if this thread has its right place in the Code Samples forum anymore...

*edit2* FIFO size is limited to 256

Moved in the development forum.

Giovanni

Mathias,
did you try to change the behavior of the TXFE interrupt to trigger on half empty?
Commenting out this line in usb_lld.c should do the trick (I think)

OTG->GAHBCFG = GAHBCFG_PTXFELVL | GAHBCFG_TXFELVL;

Kjell

Thanks Kjell for pointing me into that direction, it looks like what needs to be done, but I wasn't able to get it working.
I agree that uncommenting that line should trigger the fifo handler twice as often. It seems that disabling that line I have to cut the size of the writes to the fifo in half (which is expected), but the handler still only triggers together with SOF.
I set a breakpoint on !(sts & GINTSTS_SOF) in STM32_OTG1_HANDLER and after the initialization it didn't ever trigger.

I'm a bit clueless right now what to do next... any ideas?

Mathias wrote:Thanks Kjell for pointing me into that direction, it looks like what needs to be done, but I wasn't able to get it working.
I agree that uncommenting that line should trigger the fifo handler twice as often. It seems that disabling that line I have to cut the size of the writes to the fifo in half (which is expected), but the handler still only triggers together with SOF.

I'm thinking there may be a problem with either the interrupt masks, or the way the interrupt flags are tested by the handler. I have tried to figure it out, but not through yet. The interrupt handler looks a bit funny in the way it test the flags, but it may be that I don't fully understand it. It could also be a bug in the register definition file concerning these interrupts.

Mathias wrote:I set a breakpoint on !(sts & GINTSTS_SOF) in STM32_OTG1_HANDLER and after the initialization it didn't ever trigger.

That's really strange. As far as I can see, the SOF interrupt should be triggering. Maybe you haven't turned off some code optimization, and your breakpoint is at some code that is optimized away.

I wish I could help more right now, but I am a bit busy at home with kids and some painting. I'll try to check in as often as I can though.

Kjell

I think it is not matter of small changes, using deeper FIFOs will require some serious reworking, I'll not have a chance to help with this for several weeks

Giovanni

I have all code optimizations turned of and it works as intended: It doesn't trigger on !SOF, double negation, so everytime the interrupt triggers, a new frame starts. So if the FIFO is only half full, only half the data will be transmitted. It should if it triggers, on GINTSTS_IEPINT & !GINTSTS_SOF, we could fill the fifo between the SOFs.
I think the interrupt handler is not the culprit, it just doesn't t trigger. Maybe what is done in USB_OTG_USBH_handle_nptxfempty_ISR in usb_hcd_int.c is the solution: "while(TXfifoSpaceAvail) USB_OTG_WritePacket(...);" Although its in the host Interface handling.
I will try that later.

And Giovanni, please enjoy your vacation

Just a thought. According to the STM32F4 reference manual, you should allocate

2 * (mps /4 + 1)

mps : max packet size

If you have skipped the +1 part, the back-to-back transmit will fails since the FIFO does not contain a complete packet when it is finished with the previous. The extra word is used by the HW for some packet status info.

Isn't that 2*(mps/4+1) just for the rx buffers? According to 29.13.1 in my reference manual, thats the recommended rx buffer and for tx its "at least one packet and the more the better" (plus I think theres a limit of 256 bytes per fifo).

You're right, I missed that part.