| Age | Commit message (Collapse) | Author |
|---|
|
msp430x5xx: Add fix for possible bug in msp430-elf-gcc 9.3.0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There were two problems:
- dma_running flag could be checked in USB interrupt (not set yet) then higher priority
interrupt could start transfer, check dma_running (not set yet) set it to true start
DMA; then when USB interrupt continues it starts another DMA that is not allowed
- when DMA is started some registers can't be safely accessed, read can yield invalid
values (SIZE.EPOUT, SIZE.EPISO)
current implementation could start DMA for one OUT endpoint then check that another
endpoint also has data and while DMA was not started right away, SIZE.EPOUT was copied
already to MAXCNT register. Later on when DMA was started not all data was read from
endpoint due to incorrect DMA size previously set.
To prevent both cases dma_running is changed in atomic way.
Only code that actually set this value to true starts DMA, code that tried and
had dma_running flag already set simply defers DMA start to USB task.
This eliminates also need to have mutex that was there to limit access to dma_running flag
to one task only.
transfer also now has started flag that is set only after dcd_edpt_xfer() sets up total_len
and actua_len. Previously USB interrupt was disabled when total_len and actual_len were
setup to prevent race condition when data arrived to ednpoint before transfer was setup
was finished.
|
|
remove the usage of TUD_OPT_RHPORT in class driver
|
|
Signed-off-by: Rafael Silva <[email protected]>
|
|
druing the renaming int and iso endpoint configurations were swapped
Co-authored-by: Koji KITAYAMA <[email protected]>
|
|
Co-authored-by: Koji KITAYAMA <[email protected]>
|
|
|
|
Signed-off-by: Rafael Silva <[email protected]>
|
|
Signed-off-by: Rafael Silva <[email protected]>
|
|
create local register access struct and move mcu specific code
in preparation of support for other mcu families that use the LINK usb core
Signed-off-by: Rafael Silva <[email protected]>
|
|
link was chosen according to the name for the usb core on datasheets, LINK core
Signed-off-by: Rafael Silva <[email protected]>
|
|
- BOARD_DEVICE/HOST_RHPORT_NUM to BOARD_TUD/H_RHPORT
- BOARD_DEVICE/HOST_RHPORT_SPEED to BOARD_TUD/H_MAX_SPEED
|
|
|
|
overwrite grstctl on edpt_disable
|
|
|
|
Update dwc2_stm32.h
|
|
Add SOF IRQ Handler
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Minor cleanup of RP2040 code post addition of Pico-PIO-USB
|
|
pic32 sanity fixes
|
|
|
|
* Removed some compiler warnings, and cleaned out unnecessary warning suppression from CMake suppress_tinyusb_warnings()
* Made explicit family_configure_dual_usb_example() for DUAL mode examples as family_configure_target() may not generally be called multiple times for the same target
* Renamed library pico_pio_usb to tinyusb_picio_pio_usb to be clearer and avoid conflict if someone already has a pico_pio_usb in their project
* Added family_add_pico_pio_usb() method for adding Pico-PIO_SUB support to an existing example
* Allowed tinyusb_pico_pio_usb to be added to regular apps using the Pico SDK
|
|
|
|
- also add interval_log2 to isr callback
- also rename other variables
|
|
|
|
|
|
|
|
|
|
When transfer was finished rx_fifo_read() read all that
was to read RXPKTRDY was cleared allowing next packet to
be received.
Then xfer_complete was called.
Interrupt for OUT endpoint was left enable, that would not
be a problem if data was handled fast and new transfer was
scheduled.
For MSC when host sends a lot of data this interrupt that was
enabled could cause epn_handle_rx_int() to be called after
transfer was completed and next was not scheduled yet.
Without TU_ASSERT that was added to detect this, incoming
data was written past buffer provided by user code resulting
in random memory corruption.
This just blocks RX interrupt when transfer is finished,
and also only unmasked rx interrupts are handled.
|
|
TU_ASSERTS added to detect transfer inconsistency.
|
|
_mips is provided by xc32-gcc
|
|
|
|
|
|
|
|
|
|
|
|
|
