Problems writing to USB flash drive with "V" revision STM32H743

[JOwen.1]

Update: Using a USB analyzer shows that we get a one bit shift in the data when we have problems writing to a USB flash drive. It can be the CRC that is bit shifted, and other times it can be the data values that are bit shifted. This sounds like an issue with the USB port, but I have not seen any errata about this problem yet. Happens a lot more often when the CPU is busy (running a lot of peripherals). We are using the internal USB phy for 12 mbps speeds, not an external phy.

We recently started receiving the "V" revision CPU. Unfortunately, writes to the USB flash drive fail frequently. We do not have this problem with the older "Y" revision CPU. A failed write leaves corrupted files on the USB drive and it must be re-formatted. Our system is busy, with Ethernet, DMA, USB, and an SD card. We suspect there is some interaction between subsystems that the new CPU does not like, but have not found what it is yet. We are using Segger's stacks for these peripherals and Segger has not been able to find a solution.

Has anyone experienced similar problems with the V chip or have any ideas of what we could try? This is becoming a crisis very quickly!

[JOwen.1]

We have not found the root cause for the USB problems, but we did implement a workaround. We added up to 10 retries when a file transfer was detected. The retry consisted of powering off the USB flash drive, powering back on, erasing bad files, and then trying to transfer the file again. Some boards took several retry, but all were able to eventually successfully transfer the file.

[JOwen.1]

We have updated our artwork to make the routing of the USB data lines as perfect as possible. The new boards with this improved routing do not have near as many failed USB file transfers as the older artwork, but they do have failures. My takeaway from this is that when using the STM32H7xx parts, you need to be very careful with the USB data line routing and have code in place to gracefully handle failures since you are going to see some during normal operation.

[JOwen.1]

I have a little more information about this. We have found that changing settings in the AXI Interconnect Matrix registers makes writing to the USB port work much better - but we don't understand exactly what some of these bits really do that seem to help! This is making us think that the source of our USB problems might be related to internal data transfers. This would also explain why we see USB problems a lot more frequently in a fully loaded system rather than in a smaller example project.

To summarize our changes:

1. A normal system gets USB errors 60% of the time when transferring 100 MB of data.
2. Increasing the priority of the INI 1 (D2 to D1 bus -where USB is located) from 0 to 15 reduces the errors by 10%. We understand this setting, it just gives the USB a little more priority on the AXI bus.
3. Here is what we don't understand. If we set the WRITE_ISS_OVERRIDE and the READ_ISS_OVERRIDE bits, the number of errors drops down to 20%! 20% is a lot better than 60%, but it still is not perfect.

These bits sound like something Scotty would say to Captain Kirk, but we don't know what they really do. Also, does setting these bits cause problems in other places? If anyone has any experience with these settings, we would like to hear about it.