USB descriptors larger than 127 bytes don't work (STM32 OTG)

[iggarpe]

You can read the details here:

https://sourceforge.net/tracker/?func=d ... tid=995489

I'm posting here so that anyone developing an USB device with this platform is warned, and also to discuss the modifications required to fix it.

Long story short, the EP0 registers are different from the other EP registers, and in particular the DIEPTSIZ0 register packet size bitfield (XFRSIZ) is only 7 bits wide (hence the 127 byte limitation). DIEPTSIZn for other endpoints is 19 bits wide. Also it is worth noting that the packet count bitfield (PKTCNT) is only two bits wide, while it's 10 bits wide for other endpoints. This is what the ChibiOS driver does when writing to this register:

- If data len is zero, then XFRSIZ=0 PKTCNT=1.
- Otherwise, XFRSIZ=len, PKTCNT=(XFRSIZ + in_maxlen - 1) / in_maxlen.

My descriptor is 0x88 bytes, so when XFRSIZ is written ends up with a 0x08 size value since it's got only 7 bits.

I've traced the execution of a working example of the ST OTG library with a descriptor larger than 127 bytes, and this is what it does for the special case of EP0:

- PKTCNT=1 always.
- If data len <= in_maxlen, XFRSIZ=len.
- Otherwise, data_len = in_max_len, enable interrupt.

Then in the interrupt service routine anothe transfer is set up until all the data is transmitted. Obviously, the total amount of data to transmit and the remaining amount are stored in the EP0 state.

Cheers.

[Giovanni]

Hi,

Thanks for opening a ticket for this, the issue has been discussed in the past: viewtopic.php?f=3&t=699

The fix is what you described, the implementation requires special code paths in the code for EP0, I already know I will not like that I don't see the point in limiting EP0 in HW, in order to save some gates? bad idea.

Giovanni

[etmatrix]

Sorry I forget to open a ticket for this problem. I tried to solve the problem, without success.

@iggarpe are you trying to solve it?

[avrhack]

Did anyone solve this? I can't believe we're two years on from the original post and it's not working. That means no-one has ever done a dual-cdc usb device with ChiBIOS? That's a crazy and serious defect in my view......

I don't disagree with Giovani that it's a stupid thing for STM to do in order to save a few gates, but the reality is that there are going to be cases where the descriptor is more than 127 bytes long so this needs to be handled. I wouldn't mind fixing this but I suspect it will take me ages to do when someone with a good knowledge of the STM32 usb_lld could knock it out easily.

As it stands now I'm going to have to dump ChiBIOS altogether and I really don't want to do that but what other choice is there with such a huge limitation?

[Giovanni]

Hi,

A solution has been proposed here: http://sourceforge.net/p/chibios/bugs/471/

I rejected it because it fixes a problem in the low level driver in the high level but you could give it a try.

Giovanni

[avrhack]

Hi,

A solution has been proposed here: http://sourceforge.net/p/chibios/bugs/471/

I rejected it because it fixes a problem in the low level driver in the high level but you could give it a try.

Giovanni

Interesting. Seems like a very simple and effective fix but as you say it's not necessary for other architectures. But surely this code could be very simply adapted to the lld for STM32? Or is it just that you don't see this as the major issue that some of us do?

[Giovanni]

You may try it, it is just not "right" to affect all ports because limitations of one.

Giovanni

[avrhack]

You may try it, it is just not "right" to affect all ports because limitations of one.

Giovanni

I agree with you, and I am trying it now as I have no other choice. What I don't understand is why this has been outstanding for so long but isn't deemed worth fixing properly in the STM32 LLD when it's such a serious defect.

**EDIT**

Have now tried this; patch didn't immediately apply as I'm on 2.6.3 but a quick 'hack' got it in there as it's not complicated. The device enumeration is now getting further - at least it sees that there are 7 endpoints for example - but it still doesn't work. It 'feels' like only the first 64 bytes are being returned. Guess I'd better break out gdb *sigh*.

[avrhack]

OK so I got this working on an F303 using a twin-CDC descriptor. Obviously it's a hack as I hate using patched versions of ChiBIOS - like them 'clean' so I can enjoy the fruits of Giovani's labour (and bug fixes! )

Hopefully this will be fixed in the next release 2.6.4 and 3.x? It's been outstanding for several years now and the fix at the HLD is really easy although to be fair having taken a quick look at the LLD it's probably a little more tricky.

I'm going to press ahead with my project as I can now use descriptors larger than 127 bytes, but if I get time I'll have another look at the STM32 LLD and see if I can port the HLD-level fix down into that driver and give it to Giovani as a patch to include in the main code and finally close this defect properly.

Still can't believe with all the hobby and commercial users of ChiBIOS no-one else needs descriptors longer than 127 bytes on the STM32!!

[Giovanni]

Note that the limitation exists only in the OTG peripheral (F2, F4 and F107), all the other STM32s use another USB peripheral that is not affected by this limitation.

Giovanni