| Age | Commit message (Collapse) | Author |
|---|
|
nrf5x: Fix DMA access race condition
|
|
Add hcd driver for frdm kl25z
|
|
da1469x: fix resume
|
|
If using a USB hub, a request outside the array size can occur
Original line:
https://github.com/hathach/tinyusb/blob/ffb257ac17f162bc5a4c26596d7a1e954db98aa5/src/portable/ohci/ohci.h#L162
It can happen in a few places but one such example is here:
https://github.com/hathach/tinyusb/blob/ffb257ac17f162bc5a4c26596d7a1e954db98aa5/src/portable/ohci/ohci.c#L460
ie. if HUB address is 5, this would be an array index out of bounds on control endpoints as `CFG_TUH_DEVICE_MAX+1` is only 5.
This fix just includes num of hubs in the reserve array size.
Fixing locally fixed this issue.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Going to suspend states disable reception on non-0 RX endpoints.
Now when USB resume condition is detected, all RX endpoints
with pending transfers are resumed.
|
|
Bit mask enabling/disabling over-run/unde-run was shifted
by one nibble, so interrupt was never enabled.
It did not force any issue as this situation could only
happen on ISO endpoints without DMA.
|
|
Add HCD driver for Renesas RX
|
|
When two tasks entered dcd_edpt_xfer() it was possible that
first disabled interrupt to setup total_len and actual_len
but second task for another endpoint enabled interrupt
between total_len and actual_len resulting in race
condition with interrupt, hence mutex is added on top of interrupt being blocked.
|
|
In multi-thread mode starting DMA in thread mode was
prone to race condition resulting in infinite loop.
It may happen on single core CPU with strict priority based
tasks scheduler where ready high prio task never yields to
ready low prio task (Mynewt).
Sequence that failed (T1 - low priority task, T2 - high priority task)
- T1 called start_dma()
- T1 set _dcd.dma_running (DMA not started yet, context switch happens)
- T2 took CPU and saw that _dcd.dma_running is set, so waits for _dcd.dma_running to be 0
- T1 never gets CPU again, DMA is not started T2 waits forever
OSAL mutex resolves problem of DMA starting from thread-context.
|
|
nrf5x: Fix EP OUT race conditions
|
|
olimex pic32 board fixes
|
|
nrf5x: Request HFXO via OS
|
|
Mynewt (similar to Soft Device) has its own reference counting for
HFXO oscillator.
So far TinyUSB requested HFXO when VBUS was detected and stopped when
VBUS was removed.
But with Mynewt running HFXO can be stopped when other interested parties
don't require HFXO anymore. This results in very difficult to track
USB transmission errors.
This change enables Mynewt specific HFXO management in Soft Device fashion.
|
|
Remote wakeup requires 10ms of delay when RESUME bit
is toggled.
It was covered for OS build.
For non-OS build simple delay based on board_millis() is
used to wait required amount of time.
Without this remote wakup may not work.
|
|
Includes were moved few lines down to restore build with Mynewt build system.
|
|
|
|
Driver for Microchip PIC32MZ family
|
|
When dcd_edpt_xfer() starts new transfer two separate problems were observed.
For both problems stream of OUT packets was pouring from host.
First problem was that total_len and actual_len were not atomic.
In case where incoming OUT packets are less (63) than MPS (64), actual_len and total_len
are set 63.
Then transfer complete from USBD is called that will schedule next 64 bytes transfer.
At that point incoming packet would start DMA if there is place in RAM, normally
it does not happen since actual_len == total_len.
If packets arrives and interrupt is raised after total_len is set (64) but actual_len is still 63 from
previous transfer, interrupt code sees that there is place in ram (1 byte) and transfer this 1 byte
to buffer that was already filled with previous packet.
To remedy this USB interrupt is blocked during transfer setup.
Second problem can happen when dcd_edpt_xfer setups xfer->total_len and actual_len correctly
but then context switch happens before xfer->data_received is checked.
If during this time two packets arrive one will be copied to RAM second will stay in endpoint with
data_received set to 1.
Then when xfer_edpt_xfer() checks data_receive flag it starts DMA again overwriting data.
To remedy this, data_received is checked together with check if data was already transferred.
If transfer was complete, there is no need to start DMA yet.
In such case data_received will be handled in same place by next xfer_edpt_xfer() correctly.
|
|
Device-only driver for PIC32MZ MCUs.
|
|
These are different Broadcom chips. The peripherals are essentially
the same. The main differences are:
* The CPU(s)
* The interrupt controller
* The peripheral base address (but not the peripherals that we use)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
definition of DEBUG breaks Microchip pic32 builds for Mynewt.
When MCU is not VALENTYUSB_EPTRI there is no need to have any
preprocessor definitions.
It may not look like a big deal but for xc32 builds, compiler
automatically force-includes some file that have structure with field name
DEBUG that result in build error in dcd_eptri.c when this file
is not really needed.
Moving DEBUG and LOG_USB few lines down should not break eptri builds.
|
|
|
|
Handle the closing of endpoints on RP2040
|
|
nrf5x: Fix race condition during startup
|
|
|
|
|
|
|
|
When NRF5x device is reset by software (after DFU for example),
power event is ready from the beginning.
When power interrupt is triggered before tud_init() finished
USBD_IRQn is enabled before it would be enabled in tud_init().
This in turn may result in BUS RESET event being sent from
USB interrupt to USB task when queue is not initialized yet.
This scenario often happens in Mynewt build where queue creation
takes more time.
To prevent this scenario USBD_IRQn is not enabled in power event
interrupt handler before dcd_init() was called.
|
|
|
|
Add a HCD driver for MSP-EXP432E401Y
|
|
|
|
The datasheet says 2KB FIFO, but accroding to many
code examples, the F1C100s has at least 4KB of FIFO memory.
This is working with cdc_msc example,
but I'm not sure, this should be checked.
|
|
|
|
|
|
|
|
|
