This fixes https://github.com/hathach/tinyusb/issues/1894. I'm not really
sure if this is the correct way to fix it, and I have not tested on all the
rest of the family members, however, this lets the i.MX1010 work again.
The problem: the latest SDK update does not enable the data cache by default
This causes an assert in board_init() when attemping to control clock
gating. I haven't investigated further as to *why* it's a problem, but it
is a problem.
Mostly copy of stm32h743nucleo.
Linker script generated by STM32CubeIDE.
Since this device has only one HS USB
board.h contains few defines that map on
board HS USB to FS because there is no
ULPI chip mounted on Nucleo board.
For FreeRTOS build:
Set interrupt priority for HS always and for FS if exists.
Don't mark IN buffers as available during the last 200us of a full-speed
frame. This avoids a situation seen with the USB2.0 hub on a Raspberry
Pi 4 where a late IN token before the next full-speed SOF can cause port
babble and a corrupt ACK packet. The nature of the data corruption has a
chance to cause device lockup.
Use the next SOF to mark delayed buffers as available. This reduces
available Bulk IN bandwidth by approximately 20%, and requires that the
SOF interrupt is enabled while these transfers are ongoing.
Inherit the top-level enable from the corresponding Pico-SDK flag.
Applications that will not use the device in a situation where it could
be plugged into a Pi 4 or Pi 400 (for example, when directly connected
to a commodity hub or other host) can turn off the flag in the SDK.
v2: use a field in hw_endpoint to mark pending.
v3: Partial rewrite following review comments
- Stub functions out if the workaround is not required
- Only force-enable SOF while any vulnerable endpoints are active
- Respect dcd_sof_enable() functionality
- Get rid of all but necessary ifdef hackery
- Fix a bug where the "endpoint lock" was used with an uninitialised pointer.
hathach