Hello Peter, many many thanks for your long and detailed answer. > On the protocol design: > > First, using CDC-ACM means sacrificing all structured communication > offered by the USB packet bus and settling for such primitive use of > USB is not a decision that should be made lightly. Almost all > applications can benefit quite significantly both in end-user > usability and in ease of implementation from an application-specific > protocol which takes advantage of what USB offers. Yes you are absolutely right. No the best idea. The usage for this protocol is to make firmware updates. In normal life it is a simple keyboard. And sending out bulk messages is the great advantage of CDC/ACM What is still puzzling me is the fact that the host controller stops any communication. That means there is really electrically no communication (bulk_out) from HC to device anymore. It seems that the host controller has shut down communication port to one particular device. unbind and bind host controller will solve the problem But anyway I will try do my best to find out the root cause of mis-communication between between both sides. > You mention device-side buffering and that the device at some point > can't accept anything more from the host. With USB this means that > you must ensure that the host will know when it must not send more. I thought sending NAK as response for each package is the correct way to tell the host "not now but maybe later.Please try again". After the internal device queue is not completely full namyore the comunication is done in normal way. But after some time HC stops completely any communication. In real life it means a huge firmware update takes long time and so it could happens the internal device queue is full. But a broken firmware update is a bad thing > The USB way to do this, were you using an application-specific > protocol instead of serial port simulation, would be to stall the > endpoint. Unfortunately CDC-ACM doesn't allow doing that. Ok. I will think about this if another way is possible > So you have to include some kind of in-band signalling for this. :\ > > This is just one reason why ACM is a poor choice for when you need > structured communication. Anyway many many thanks for your precious time and detailed answers. My conclusions and todo : 1. Thinking about design 2. Still try to find out the main reason why host controller shutdown connection Arrrghhh Just saw also USB 2.0 has some problems. Host controller is resetting after some hours but not getting in work state again. I hope in future I can make more sensible contributions to the list Best Regards Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
