STM32F7 USB OTG differences within series

[Matthew Lai]

I have a "hello world" example that works fine on a STM32F765Z6T6 (custom board). It basically waits for a USB serial port to be opened on the host side, and outputs "Hello world" every second over and over again. Unfortunately it's based on libopencm3 and my own middleware library, so the code is not easy to share.

So everything works fine on the STM32F765Z6T6.

I designed another board using a device from the new value line - STM32F730R8T6 (schematics attached). Curiously, my hello world example doesn't work on this new board - it doesn't enumerate.

I know the USB hardware works because I can program it using the DFU bootloader, and I know my code is being run because I can get a blink example to work, and it blinks at the correct frequency (crystal frequency is the same as the board that works). I verified with an oscilloscope that the blink frequency is correct, so I don't think it's a clock setup issue (I am using the same crystal as the working board, so all the clock setup should be the same?)

Unfortunately I don't have any kind of debugging interface on this board.

Before I go down this USB debugging rabbit hole, does anyone know if there's any difference in USB FS OTG peripheral between different parts in the F7 family?

Thanks!

[waclawek.jan]

ST uses various versions of the Synopsys OTG IP throughout various models, even changing them within a family, without acknowledging it in the documentation. And don't hope for any support from ST in this regard here, e.g. https://community.st.com/s/question/0D50X00009XkaAaSAJ/l4-otg-the-mysterious-bit-15-in-doepint-and-otgcoreid .

Just for fun, read out and compare content of GSNPSID register, giving the version of the OTG module, offset 0x40, undocumented by ST yet used in Cube.

JW

[Matthew Lai · Accepted solution]

Well, as it turned out, it has nothing to do with USB. I was using the unique device ID register to get a serial number for the device descriptor, and that register MOVED ADDRESS between 745/765 and 730.

On 745/765 it's at 0x1FF0 F420.

On 730 it's at 0x1FF0 7A10.

Even though the functionality looks exactly the same.

Sometimes it really feels like ST is just screwing with us for fun.

[waclawek.jan]

That's because 'F730 is in fact 'F722 or 'F723 depending on the package. Yes, some things might be more stable, but this is at least documented.

There still may be differences in the OTG module version. Can you please read out the GSNPSID register and compare and post here.

Thanks for coming back with the solution. Please select your post as Best so that the thread is marked as resolved.

JW

[Matthew Lai]

Thanks. What is the significance of it being F722 or F723? Are they considered a different series or something?

I haven't been able to find GSNPSID in the reference manuals. Do you have the address by any chance?

[Uwe Bonnes]

F722 and F723 are the same chip. F723 functionality in F722 is probably fuse disabled or not tested.

[waclawek.jan]

> What is the significance of it being F722 or F723? Are they considered a different series or something?

As I've said, ST tends to use different versions of the Synopsys OTG IP in different models even of the same family. ST does not document the differences, so you may or may not run into problems.

> I haven't been able to find GSNPSID in the reference manuals.

As I've said above, GSNPSID is offset 0x40 (i.e. at 0x50000040 for OTG_FS and 0x40040040 for OTG_HS), undocumented by ST yet used in Cube (e.g. for 'L4).

Thanks,

JW

[Matthew Lai]

0x4f54330a for both FS and HS on 730.

0x4f54320a for both FS and HS on 765.

Do the bits mean something? Or is the whole thing just a version number?

[waclawek.jan]

Thanks.

0x4f=O 0x54=T (standing for "OTG")

0x32 0x0a stands for version 3.2a (and 3.3a in case of the '730)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/dwc2/core.h?h=v5.3#n1087

JW