Defective USB Host hanging up your target

[ejeffrey]

Colossally simple, and exactly the same as for any other interrupt source: calculate maximum possible theoretical interrupt rate and do your processing in significantly less time than the interrupt period. If you have some operations that require longer time to finish and are triggered with some sort of command, just ignore the new command while things are unfinished.

Just limit the speed to USB 1.1. If the peripheral can only generate an interrupt for a whole packet, that is going to be a lot of time between interrupts. If you don't make it, improve your code until you make it. If still unable, start ignoring packets. Generic pattern which works:

This is all true, but since he doesn't have any instrumentation on how many interrupts are being generated, what tokens are being received, or much of anything else, it is premature to guess that the problem has anything to do with interrupts at all.  So far we started with "under certain host operations my microcontroller stops responding" to "how can I tell if there is a host process reading from my serial endpoint" with some stuff about mass storage filesystem operations mixed in.  The diagnostic mechanism seems to be "pick a random function in my code, post it and ask if there are any problems with it" without explaining the context. 

[peter-h]

I am trying to walk a tight line between

without explaining the context.

and posting too much detail which is guaranteed to produce no response

But I moved the goalposts from what you describe, to a requirement to be able to just dump the output data if no Host is connected. And that has been solved.

I am not posting "random functions".

[GromBeestje]

Rather then overloading with requests could an invalid request cause the firmware to hang/crash?
Eg. Windows XP used to request String Index 0xEE to receive MSOS1 descriptors, which could crash firmwares that don't perform bound checking on their USB requester handlers.

[peter-h]

The ST Cube software is dated variously around 2012 so I would expect a presumably well known winXP behaviour to be known by then.

[GromBeestje]

That was merely an example of an occurrence of bad requests by hosts from the past.

[peter-h]

I did a search of the project for 0xee and MSOS1 and nothing turns up

[peter-h]

Just an update in case anybody finds this one day.

IMHO USB is full of sh*it and the only reason why it works "ok" today is because billion $ commercial interests have spent countless man-years fixing various issues, and with each USB product vendor wasting this time and money in-house independently.

I've managed to eliminate some very subtle problems by doing 2 things

1) checking for VBUS=1 before sending any data out of USB

2) checking a flag which is set/reset by CDC_Init_FS() and CDC_DeInit_FS(). Experts tell me that that is all one can do without having a custom driver.

Note also that the ST Cube code uses the heap (malloc and free) in these two functions, so your product will eventually crash.