10 byte Mode Sense causes a stall

[denverh2000]

Hello,
I have several different CircuitPython boards which seem to hang when a 10 byte Mode Sense command is issued. I also have two that don't. Those two have bootloader version 1.23.0, the others all have the latest: 3.7.0. From what I can see in the code, that command should work just as well as the 6 byte Mode Sense command. I'm trying to use these boards on FreeBSD, which issues a 10 byte Mode Sense command as part of the device initialization. That causes the device to stall, with the result that it never gets initialized. I tried sending a similar command on a Linux system with the same result: it timed out. Any ideas about why this is happening?

Regards,

Denver

[dhalbert]

Which ones work and which don't? Are they M0 vs M4 or vs nRF?

[denverh2000]

The two that work are Gemma M0 and Trinket M0 (both bootloader 1.23.0). The others are Monster Mask, Trellis M4, Circuit Playground Express, Hallowing M0, Pygamer, and Pyportal (all with bootloader 3.7.0).

I should also add that the CDB that causes the stall is 5A 00 3F 00 00 00 00 00 C0 00.

[dhalbert]

Ah, I misunderstood, so it's strictly the version. Thanks.

[denverh2000]

Yes, that's how it looks. I haven't tried newer code in the two boards that currently work, or the older version in one of the ones that doesn't. I might try that this weekend if I get a chance.

The boards that stall in normal mode also fail in bootloader mode (double reset), but in a different way. I'm less concerned about that at this point though. I would like to at least get them working in normal mode. The two that work in normal mode also work in bootloader mode.
Thanks,

Denver

[dhalbert]

The MSC code that responds to the MODE SENSE requests is different in the bootloader and CircuitPython. I actually thought you meant only that you were seeing an issue when the BOOT drive was showing, but you're saying it's also true for CircuitPython for CIRCUITPY? Try the same version of CircuitPython across the different boards to confirm. Underneath all the atmel-samd boards use the same code in CircuitPython, modulo slight USB hardware differences between SAMD21 and SAMD51.

[denverh2000]

In normal mode (CIRCUITPY) the initial 10 byte mode sense command during initialization causes the device to stall.

In BOOT mode the board responds to inquiry commands with an error. The CDB is 12 00 00 00 24 00. The system simply reports that the command completed with an error. I haven't figured out yet what the error is. However, I'm more interested in solving the CIRCUITPY issue with the mode sense command. I'll worry about the BOOT problem later.

Sorry about the confusion.

Thanks,

Denver

[denverh2000]

I have the latest version of CircuitPython on all the boards that don't work - either 4.1.2 or 5.0.0-beta.5. The Gemma had 2.0.0, and when I updated that to 4.1.2 it also began to behave as the others, with 10 byte mode sense timing out, although BOOT still works. I haven't done anything with the Trinket, other than to confirm that it also has version 2.0.0 of CircuitPython installed.

So for the CIRCUITPY device the SCSI commands are handled by CircuitPython, and for the BOOT device they're handled by the bootloader? I thought the bootloader was always responsible. Again, sorry to have confused things.

Thanks,

Denver

[dhalbert]

So for the CIRCUITPY device the SCSI commands are handled by CircuitPython, and for the BOOT device they're handled by the bootloader? I thought the bootloader was always responsible. Again, sorry to have confused things.

No problem. It is confusing. They both have their own independent MSC implementations. The bootloader does nothing but start CircuitPython when CircuitPython is present. The bootloader presents the fake BOOT drive, and its implementation is fairly stripped down.

[denverh2000]

Ok, that makes sense of the different behaviors between the two modes. So in normal, CIRCUITPY mode, the problem is with the 10 byte mode sense command causing the device to stall. Somewhere between CircuitPython versions 2.0.0 and 4.1.2 something changed. If it will help I can try to narrow that down.

[denverh2000]

I think I see what's going on with the BOOT device. The host issues an Inquiry and the device responds with appropriate looking inquiry data, followed by 13 bytes of status (or so I assume - I'm not that familiar with SCSI over USB), which should be
55 53 42 53 01 00 00 00 00 00 00 00 00
However, the first four bytes are in reverse order:
53 42 53 55 01 00 00 00 00 00 00 00 00
After that I don't see any further activity involving either endpoint.

Thanks,

Denver

[denverh2000]

Ok, that makes sense of the different behaviors between the two modes. So in normal, CIRCUITPY mode, the problem is with the 10 byte mode sense command causing the device to stall. Somewhere between CircuitPython versions 2.0.0 and 4.1.2 something changed. If it will help I can try to narrow that down.

I've narrowed it down to somewhere between 4.0.0.A2 and 4.0.0.B6. I didn't have much luck with any of the versions between those two. I tried most of them on the Gemma, and a few on the Trellis, the Hallowing, and the CircuitPlayground. None of them would actually run - lights would come on briefly, then go out. So 4.0.0.A2 works, and 4.0.0.B6 doesn't.

Thanks,

Denver

[dhalbert]

There were many changes between those versions :) . I'll take a further look, though I will need to set up a FreeBSD system. I can't get to this right way -- sorry.

[denverh2000]

There were many changes between those versions :) . I'll take a further look, though I will need to set up a FreeBSD system. I can't get to this right way -- sorry.

Ok, thanks.

[denverh2000]

I just tried CP 5.2 and bootloader 3.9. The new CP version cures the CIRCUITPY device problem (the 10 byte mode sense stall) on FreeBSD. However, the BOOT device still returns reversed status bytes, so that one is still there. But at least the normal CIRCUITPY device is working as it should, so that's a big improvement.

Thanks,

Denver

[dhalbert]

@denverh2000 That's funny because I didn't know we'd fixed that.