Drivers sometimes send SET_LINE_CODING in an attempt to stimulate a response from the device. If you look carefully at the notifications on the interrupt pipe, there's info that is difficult to obtain otherwise (there's no SETUP to directly request it). It's conventional for devices to send a serial line state notification over the interrupt pipe in response to a SET_LINE_CODING command.
Your device can't NAK setup packets; that's not defined behavior in the USB spec. Your device can either ACK (in which case the host begins the data or status phase, as appropriate) or be completely silent. If you don't respond, the host controller will try three times, and then will declare that your device is not responding. Its best to avoid this. You can NAK the data-out stage but that won't do much good; the host will just wait patiently until it times out, and then it may decide your device is broken. If you can accept the SET_LINE_CODING data phase, and then just store the data (don't bother parsing it), that would probably be the best thing to do. Return the stored data to any subsequent GET_LINE_CODING commands. When you get a USB reset, decide whether you want to reset that buffer to its boot-up value or leave it unchanged. Best regards, --Terry From: [email protected] [mailto:[email protected]] On Behalf Of Kustaa Nyholm Sent: Friday, March 20, 2015 12:44 To: [email protected] Subject: Re: Yosemite USB CDC ACM Terry Moore wrote: Excellent, hope you can borrow the unit. Here is an update. I got the Beagle 480 set up and of course the problem did not show up for an hour! Things were running very smoothly. After a couple of device resets I was able to reproduce and capture it right after the communication gets going. Looks to me like I'm about to discover the problem. Things go shout after Yosemite sends SET_LINE_CODING. Looking at my device firmware code, this is no wonder as I ACK that but don't prepare to receive any data. I've not verified that yet, but question is, is it ok just to NACK this as this is an optional ACM request? Is it also ok to NACK SET_LINE_CODING and INTERFACE ? Actually what happened here is that originally I was ignoring all the optional requests but some apps on Windows, like Teraterm (or was Hyperterm, don't recall) refused to talk to my device because they insisted getting response to GET_LINE_CODING, so I added (fake) support for that. At the same time I thought I'd better ACK also SET_INTERFACE,SET_LINE_CODING and SET_CONTROL_LINE_STATE without thinking that I need to also conform to the protocol, my bad. Anyway, if my analyses is correct, the next question is who or why is Yosemite sending SET_LINE_CODING, I'm not setting any baud rates,char size etc but relying on the port settings 'as is' when I open it. And why is this not happening every time, like I said i had good spell of about an hour, and that was not the only time. br Kusti -- Sent with <http://www.getpostbox.com> Postbox
_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
