PORTS Forum
Ports and Interfaces => USB => Topic started by: ulao on July 01, 2017, 04:33:46 pm
-
If i wanted to set a busy flag in my USB firmware so that any request feature or normal get/set request is rejected, could I some how return data that would force an error?
Or would I have to return some flagged data in my payload to catch on the receiving end?
a)
usbMsgLen_t usbFunctionSetup(uchar data[8])
{
if (_BUSY) return 0; //reject with 0
...
b)
usbMsgLen_t usbFunctionSetup(uchar data[8])
{
if (_BUSY) { Buffer[0xff] return 0; } //reject with first byte of FF to tell the software there we are busy.
...
As it stands if the USB has some type of error (i.e. PID STALL) it returns an error and I catch that in my code. I'm just not sure how error handling works. I'm pretty sure the return to usbFunctionSetup is the length of the data. Guessing a return of 0 means data length of 8 but not sure.
usbMsgLen_t is my return type for usbFunctionSetup
usbMsgPtr points to my payload array
I don't see any room for error handling.
-
STALL means request not supported.
NAK means busy (temporary state).
For a vendor-defined Get_Feature request, you can define codes for the firmware to return to indicate "rejected" or other conditions.
Not sure if that answers your question.
-
it helps a bit, so I'm trying to figure out how to get my firmware to report NAK (aka busy) based on some condition. I'm just not certain no how I can return this via code(firmware). This may be a question for the usb firmware API...
-
How to return NAK varies with the chip architecture as defined in the data sheet.