Debugging and USB - mass bulk

[mikyak]

Hello!

There is the following obscure scenario when using bdm for debugging during USB firmware development.
For UART debugging, I stopped using it because it was based on busy waiting code, however it is unexpected that BDM
also causes (timing) problems.

Here is the test scenario as it is displayed in the analyzer without debugging.
1. Enumeration passes fine
2. Getmaxlun is answered
3. Scsi inquiry is answered, but csw status is not sent.

When debugging with bdm (only event logging) strange behaviour occurrs:
1. Enumeration passes
2. For getmaxlun, sometimes zero data is sent in the data packet, altough one byte was written in the USB FIFO buffer.
3. After responding to scsi inquiry with the amount of data expected by host (36 bytes), there is a transaction that is displayed as a malformed command. It contains an IN packet. Is this a ghost transaction / request on the pc stack from before that was not processed, or possibly a request for the CSW status ?
4. Sometimes the response to scsi inquiry is not recevied at all - according to the analyzer.

Should the csw status be sent when there is an EOT (end of transfer interrupt) after the inquiry data has been sent ?

Is it possible that the BDM and the hardware analyzer are interfering , or that a timing delay is caused by BDM
which affects behavior ?

Kind regards!

[Jan Axelson]

I haven't used BDM debugging, but yes, if communications are normal without the debugger and not normal with it, it sounds like the debugger is interfering with communications or possibly just not reporting accurately.

What were you trying to see that the analyzer wasn't showing?

Is the host asking for the CSW by sending IN token packets on the bulk IN endpoint?

Are you developing the host or the device?

Jan

[mikyak]

Hello!

I am developing a device driver.

Here is the output from the analyzer.
My question is whether the status wrapper should be written in the USB FIFO right after the scsi answer,
and sent in a single transaction;
Or should I wait until there is an interrupt confirming that the scsi answer has been sent,
and then send the status wrapper?

Analyer Output:
-GetMaxLun
-Inquiry
--Command Transport
---OUT Transaction      8 Bytes
---OUT Transaction      8B
---OUT Transaction      8B
---OUT Transaction      7B
--Data Transport
---IN Transaction         8 Bytes
---IN Transaction         8B
---IN Transaction         8B
---IN Transaction         8B
---IN Transaction         4B
-Malformed Command
--Data Transport
--- IN Transaction
----IN Packet
----DATA1 Packet          NoData
----ACK Packet
-Reset (21.5ms)

Kind regards!

[mikyak]

Ok, so maybe malformed command is a glitch in the analyzer.
When the status wrapper CSW is sent right after transfer of CBW is finished, then it is received ok.
Busy waiting until CBW sending finished worked, but I suppose that an interrupt version would be better.

Or do you think, that since the device is a slave of the host, busy waiting is better ?

[Jan Axelson]

The host doesn't care whether the device firmware internally uses interrupts or polling. An endpoint with data to send can send it on any received IN token packet. 

Jan