cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F407 USB OTG_FS - OTG_FS_GRXSTSR register invalid

dbristow
Associate

I'm working on implementing USB Host support for the STM32F407 without using the STM32 HAL. I've followed the datasheet and gotten as far as sending a GetDescriptor packet (though I haven't confirmed that on the logic analyzer yet), but I don't know if the peripheral has received a message back as the GRXSTSR register seems to be invalid.

The value remains unchanged from initialization through to completing the port reset and sending the GetDescriptor packet, and is 0x1621E30E.

 

Bits 21, 25, 26, and 28 are high in the reserved section, which doesn't match the reset value of 0x00000000.

The channel number is 0b1110 = 14, which is larger than the 8 channels the peripheral has.

The data PID is 0b11, which is MDATA, and the byte count is 230.

The packet status is 0b0000, which is reserved.

The GINTSTS register is 0x14008829 and HPRT is 0x21401, which indicates there isn't actually any data received as the RXFLVL bit is low, meaning I can't pop this register with GRXSTSP as per the datasheet.

 

Any pointers for what my next steps are? The HAL is able to enumerate a USB device as a host, so there shouldn't be any hardware issues.

 

Additionally, the datasheet appears to be incorrect by stating "14. Program the OTG_FS_HPTXFSIZ register to select the size and start address of the periodic transmit FIFO for periodic transactions" (RM0090 Rev 19 Page 1336), but consulting the register on page 1291, all those bits are read only.

1 REPLY 1

> I don't know if the peripheral has received a message back as the GRXSTSR register seems to be invalid

If GINTSTS.RXFLVL = 0, as you write subsequently, there's no point analyzing content of GRXSTSR.

One potential source of problems may be, if you look at USB registers using some sort of debugger which reads out and displays content of multiple registers automatically (which essentially are all visual debuggers, command-line gdb here may have an edge in this very particular case, or using other means of debugging such as writing some simple monitor or other means of observing content of particular registers) - if the debugger reads out the FIFO (by reading GRXSTSP), if empties it and subsequent reads are pointless.

JW