Bryan sent me some traces a couple weeks ago, and I finally got a chance to look at them. I think I may have found the problem, and here's my analysis:
In capture 5, index 6291 (at 5:23:216.359) I see the following data being sent to the pyboard:
Code: Select all
55 53 42 43 31 00 00 00 00 00 00 00 00 00 06 1B 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
This is essentially a SCSI command wrapped up in a USB packet. The 06 is a length, and the 6 bytes after that is the actual SCSI command, which would be:
If you examine that (see page 221 of this document:
http://www.seagate.com/staticfiles/supp ... 93068c.pdf) then we see that this is a START_STOP_UNIT command.
The non-zero data is byte 4, which has the START bit set. So the Mac is sending a START_STOP_UNIT with START set to the pyboard (essentially to say wakeup, I've got something coming).
Now if we go and look at the code, in the micropython/stmhal/usbdev/class/cdc_msc_hid/src/usbd_msc_scsi.c at the SCSI_StartStopUnit function (line 447) we see this:
Code: Select all
static int8_t SCSI_StartStopUnit(USBD_HandleTypeDef *pdev, uint8_t lun, uint8_t *params)
{
USBD_MSC_BOT_HandleTypeDef *hmsc = pdev->pClassData;
hmsc->bot_data_length = 0;
// On Mac OS X, when the device is ejected a SCSI_START_STOP_UNIT command is sent.
// params[1]==0 means stop, param[1]==1 seems to be something else (happens after the
// device is plugged in and mounted for some time, probably a keep alive).
// If we get a stop, we must really stop the device so that the Mac does not
// automatically remount it.
if (params[1] == 0) {
((USBD_StorageTypeDef *)pdev->pUserData)->StopUnit(lun);
}
return 0;
}
I looked at where this is called and params is basically a pointer to the SCSI command block, (the 0x1B bytes in the packet above), and it should be looking at the START bit, which is in params[4] not params[1].
params[1] is 0, so the code is incorrectly interpreting his as a STOP command instead of a START command. So it goes and shuts things down.
Back to the trace, Index 6224 is the response to the START_STOP_UNIT, and index 6229 is a READ (0x28) command, to which the pyboard doesn't respond (since it was just stopped). This causes the STALL in the trace.
The host tries a few more READS later on, which all STALL, and it eventually decides that things have gone bad and pops up an error.
So, if somebody could try editing that file
https://github.com/micropython/micropyt ... csi.c#L457 and change the params[1] to a params[4] and see if that fixes things, that would be great.
