USB (STM) Firmware bug - Virus TI

#1

Im trying writing a custom USB midi driver for my Virus TI....

and Ive found a bug i the way the STM host library handles interfaces, which means the interface descriptions are corrupted, and also it will not read all interfaces.

the bug is in: STM32_USB_Host_Library/Core/Src/usbh_ctlreq.c

basically, it assumes one interface description per interface but this is incorrect since, there can be alternative interfaces descriptions (which the TI has one, hence why I stumbled on the issue)

so my questions are:
- is this the latest version of the library?
- so I just update my copy , or is there a better way....?

Ive currently fixed it so it takes one of the settings, as it appears there is no behaviour for correctly dealing with alternative settings. (actually has numerous bugs in this area)

Also Ive noticed the current 'architecture' for handling usb hosting is not really very flexible if we start adding multiple drivers. the usb core code, only allows for one registration per class... either we change this, or we should put the firmware such that alternatives can be installed.
e.g. we might need a particular 'driver' for a specific device, even though it is a midi streaming subclass.
(becomes even more obvious when you start handling vendor specific classes, where having one implementation makes no sense at all)

Also... on first glance, it looks like a particular device is of one type... e.g I'm not sure it can handle the fact that a particular device might have (e.g.) a midi interface and also an audio interface.... the current implementation appears to just match the first one according to the order they are listed in usb_conf.c
I mention this, as this is an issue for the Push 2, where I will be using a midi handler for one interface, and a vendor specific for the LCD display.

talking of Push 2...
can you confirm if the STM32F4 support USB 2, or just 1.1?

Im getting a message when inserting the Push 2...
"Please use USB2.0 socket for Push 2"
and its not finding any interfaces.... is this a hardware limitation or do I just need to dig more into the STM32 hot Library?

#2

as a positive, got the Virus TI working directly over USB MIDI on the Axoloti.
(just thinking about how to handle the vendor class handler a little more generically)

#3

Perhaps we should make a developer category on this forum, this sort of discussion could look scary to casual users. But even when it is a separate category, it will show up on the main community page. Opinions?

I stumbled on a composite device that has a HID interface as the 1st, MIDI as 2nd : Akai MPK mini mk2.
That didn't work, and fixed in commit https://github.com/axoloti/axoloti/commit/b7df04e8254e77d5111c3d00e978be403d29b8aa
I haven't encountered USB devices with alternative interfaces.

Not sure, comes from http://www.st.com/web/en/catalog/tools/PF259243#
I vaguely recall dealing with a bug in there that was eating like 90% of the cpu time in an interrupt... I do not assume that the ST USB host library is bugfree.

USB2 full speed it is, USB2 high speed is supported too but that requires a separate high speed PHY chip, not provided on Axoloti Core. Push 2 might be trying to tell you it needs USB2 HS.

#4

I think the forums might be more approachable with a more traditional forum layout, where when you are at "home" you have several categories to select from right off the bat, instead of seeing all the threads at once from every category, with filters o the top bar. Perhaps just have a preview for each category of the most recently active thread within that category.

#5

+1
for example I'm using http://forums.scopeusers.com/ (The Creamware/SonicCore users forum) since 2001 and that kind of layout is still a (well tested indeed) perfect way to do a technical/user/patches/etc. forum, IMO.

#6

ok, created a new category for developer discussions... Ive also switch the home page such that it now shows categories as the first (you can click on latest to see previous view) , its quite nice, as it still shows latest in each category.

I don't want to hide it from the home page, as for developers, they will just miss any post in it,
but an option ( which Ive not done) is to have a 'closed group' for developers, this way the category/topics would only be shown to invited members only... but I think dividing the community is probably not a good idea... as we don't know if new members will be interested etc.

so lets see how this goes for now.

back on topic....

USB2 HS, ok will check the push 2... this could well be the issue. (hmm, need to check my other controllers I think the Eigenharp Alpha is USB2 HS) , not a big issue, the PI2 as a master is looking increasingly attractive.

Alternative settings, yeah, its odd, even the Virus is not really using it, but it completely screws up the handling in the STM code which assumes one descriptor/setting per interface.
(my 'fix' just stops the corruption caused, rather than support alternative settings, as I think your right its not used often)

composites device, yeah these are really common... frankly STMs implementation is very naive.
yeah I saw your 'fix' for the mini mk2, but really it just is a band-aid... what if you also wanted to support the HID interface as well?

as I said i think there are two fixes...
- replace the STM implementation, for something that allows per interface class implementations.
- create a 'proxy' class for each interface class, which then can allow for implementations inserted.

neither is trivial, but the later probably is 'safer', and frankly the USB host code we have already needs re-visting and cleaning up anyway (I did do quite a bit on the usb midi host, but there still is a bit of dead code in there)

essentially this would mean, the STM code, would continue to match the first interface to the first interface class to hit the proxy. and the proxy then would then hold a list of known implementations to find the match.
this match could included checking not only classes, but also things like VID/PID.
(which is what Im doing on the Virus implementation, which needs a message sent to put the Virus into USB midi mode)

my current thought is to do something which, moves us in this direction, even if its not a full implementation.

the other thing Id like to do is to add some firmware 'preferences' to the preferences dialog, such that you can add 'flags' to optionally compile in bits of firmware.
(the more custom devices we have, the less likely we are to want them all in the firmware)

#7

ok, pretty certain Push 2 is USB 2.0 High Speed, so will not work with axoloti.
it appears the Push 2 can detect its not connected to high speed, and changes its description and also presents no interfaces to the host.

my Eigenharp Alpha also uses high speed, but doesnt do anything like this... but Im sure wont be useable either.

so looks like I will need to use a PI2/BeagleBoard black which supports USB 2.0 HS , oh well, in some way easier for me, as I have the code working on Linux anyway.

#8

Yes, it does not address opening multiple classes, but it fixes a common use case.

I'm hoping that STMicro will publish a major update to the USB host library sooner or later, that adds hub support and other improvements. USB host performance is a concern...

I'd rather avoid firmware divergence, it explodes the number of things to test.

#9

hopefully STM will reconsider their host library, but wouldn't hold my breath :smile:

firmware divergence, I understand that... but we also don't want to have a whole load of bloat (code, cpu, memory) for lots of different devices. also its possibly users may want to slot in their own code, that they don't want to contribute....
its like compile in modules for a kernel... the kernel dev group, only test the core, not all the modules, its assumed these are maintain/tested by their respective developers. (e.g. you can't test the virus code, as you don't have one to test with)

I think if we don't allow some flexibility in the build system, some developers will be forced to fork the main line, and then that leads to the possibility of divergence, something we definitely want to avoid.

(note: we are in early days for axoloti, so if I'm already kind of needing this for the Virus, it seems likely we are going to need it as users/developers get more ambitious)