#10 MSC BOT case 5: stalling of bulk-in too early?

[Michael Teichgräber]

I observed the problem described below after I had added a rudimentary Mode Sense command to msc_scsi.c, which only returns the mode parameter header, but no pages (This allows for instance to report a "write protected" flag to the host).

This command so far seems to be the only one that regularly returns less bytes than expected by the host, i.e. the residue value is not zero. In BOT terminology this corresponds to case 5. Msc_bot.c already seems to get this right, as the behaviour required by 6.7.2. is already implemented (at the end of HandleDataIn).

Unfortunately there remains a problem: Since the "stall" of bulk-in is issued immediately after the USBHwEPWrite() in HandleDataIn, it is possible that the message actually is not transmitted to the host. I suppose the LPC, after it received the "Validate Buffer" command, waites until it gets an IN Token. If the stall command is called too early, the buffer containing the answer to the Mode Sense probably gets ignored and the Stall Msg is returned instead.

If Debug output is enabled, the problem does not occur: Apparently the DBG("stalling DIN") call seems to delay just long enough to allow the answer message to be sent at the next IN token, and to have the stall take place after that, not instead of it.

I have appended a workaround that delays the stalling of the bulk-in pipe until the next NAK occurs, i.e. the next IN-Token is received (and no filled buffer is available). So HandleDataIn not directly stalls bulk-in, but now enters an intermediate eStallIn state.

[The (CBW.bmCBWFlags & 0x80) test has been necessary as the USBCV test suite sometimes issues a Test Unit Ready command with inverse (Host-to-Device) direction. Since also in this case HandleDataIn is called, it must be prevented that bulk-in is stalled (BotStall does this internally too).]

To help reproducing this I also appended the mode_sense patch.

Michael

[Michael Teichgräber]

Case5 Workaround, Mode Sense patch

[Nobody/Anonymous]

Logged In: NO

I've just discovered this exact problem and come to exactly the same conclusion about what was happening.