| Age | Commit message (Collapse) | Author |
|---|
|
state by a hardware reset
|
|
memcpy implementations
|
|
|
|
|
|
|
|
|
|
- rename reset_ep0_pid() to reset_ep0()
- minor update log message
|
|
|
|
|
|
RP2040 device controller does not seem to clear pending transactions
configured in EP0 buffer controls when the host aborts a control
transfer. This causes assertion failures, including when a buffer
AVAILABLE flag set for a previous transfer causes an unexpected
transaction completion.
|
|
- fix warnings build hcd max3421 with rp2040
- add tinyusb_host_max3421 target for rp2040 cmake, -DMAX3421_HOST=1
will enable this
- add max3421 driver implementation for rp2040 family
- update tusb_config for host to allow easy enable host selection for
rp2040 (default/pio-usb/max3421)
|
|
|
|
change tuh_int_handler() to take in_isr as optional parameter (default =
true)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit makes it so that when setting the START_TRANS bit in the
SIE_CTRL register, along with some other bits, we first set all the
other bits, then wait some cycles, and then set the START_TRANS bit.
Doing so protects against a situation where the USB controller is
reading the register at the same time and gets an incorrect value.
This mirrors the procedure already applied to buffer control
registers.
|
|
|
|
|
|
|
|
temporarily disable codespell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ordering by element size prevents alignment holes, and as a consequence the
host mode version of the struct is the same size as device, as pad bytes at
the end are used instead.
|
|
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.
|
|
The next change to the driver requires the export of these functions. Leave the
lock unimplemented for now.
Also move hw_set and hw_clear aliases into the top-level header file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IAR generates warning Pe161 'unrecognized #pragma'.
|
|
IAR generates warning Pe188 'enumerated type mixed with another type'.
|
|
IAR generates warning Pe111 'statement is unreachable'. In a couple of
cases, replace return statements with TU_ATTR_FALLTHROUGH; because some
compilers apparently can't figure out that the return statements are
unreachable but do whinge about an imagined fall-through without them!
|
|
Some compilers don't support the GNU extension `typeof` so their definitions
of `hw_set_alias` can't inherit their type from their argument, and the best
we can do is have `hw_set_alias` act the same as `hw_set_alias_untyped`.
This requires an explicit cast when the macro is used instead, otherwise
IAR generates error Pe132 'expression must have pointer-to-struct-or-union
type but it has type "void *"'.
The same goes for `hw_clear_alias`.
|
|
IAR generates error Pe118 'a void function may not return a value'.
|
|
|
|
|
