Part of what misled me was the driver I have been studying. It has a variety of code under a "dma enabled" flag, which I wrongly assumed was for HS mode only and therefore was not relevant for my FS only driver. I was entirely wrong about this.
I see the following series of events once I get this all working:
Int -- Reset 04801020 0 Int -- Speed enumeration done 04002020 0 Int - Rx FIFO not empty 04000030 49 Setup status (rxp): 010C0080 8 bytes on EP 0 (06 00) Setup: 01000680 00400000 Int - Rx FIFO not empty 04000030 49 Setup status (rxp): 01080000 0 bytes on EP 0 (04 00) Int -- OUT endpoint 04080020 49 OUT all reg: 50000818 00010000 OUT EP0 int reg: 50000B08 00000008These are my debug messages and won't mean much to you (or even to me in a few weeks), but here is the sequence of events once the chip boots up:
Note that when an Rx FIFO interrupt happens, your job is to read the read status pop register and examine what that gives you. It may (or may not) indicate additional data to be read from the FIFO. If there is additional data, you read it from the FIFO register at offset 0x1000, not by addtional reads to the read status register.
Also note that the datasheet shows a 4K region allocated to the FIFO register. You only ever read from the first 32 bit location.
Our job now is to respond with a device descriptor. The host keeps sending the same setup packet trying to get it, and tries beating us over the head with resets and retries. You have to admire its persistence.
Tom's Computer Info / tom@mmto.org