Electronics > Microcontrollers

Defective USB Host hanging up your target

<< < (6/7) > >>

ejeffrey:

--- Quote from: Siwastaja on February 06, 2023, 04:46:23 pm ---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:

--- End quote ---

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


--- Quote ---without explaining the context.
--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page