| Age | Commit message (Collapse) | Author |
|---|
|
Mcu specific
|
|
Updated the clearing of the status register bits to use a straight '=…
|
|
The IAR compilier does not resolve references to fields in the anonym…
|
|
|
|
|
|
|
|
|
|
Solve problems with CCRX toolchain
|
|
structs defined within the usbh_dev0_t and usbh_device_t structs as they are defined. The problem seems to relate to the placement of the 'volatile' keyword at the struct level. I fixed the problem by removing the 'volatile' from the struct level, and instead placing it on each of the field declarations within the structs.
|
|
rather than an '|='. Use of the latter caused an extra, unwanted read of the status register before the write-to-clear operation, which, in some cases, allowed new status bits to assert (relative to the initial read of the status register two statements earlier), and then be cleared blindly and unconditionally during the write-back. This had the potential (and, in my case, observed) effect of dropping the handling of an enabled interrupt. Ultimately, the system would lock up in a busy state, with no hope of clearing the condition. See Issue #1339 for more information.
|
|
Enhance rhports management
|
|
Set the standard inquiry response additional length field.
|
|
* The standard inquiry response additional length field needs to be set to
the length in bytes of the remaining standard inquiry data (i.e. N - 5),
otherwise the kernel driver issues a warning about short inquiry response..
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TUSB_OPT_DEVICE_ENABLED still usable for backward compatible
|
|
|
|
Add concurrent host and device example
|
|
|
|
|
|
nrf5x: Fix DMA access race condition
|
|
fix build with latest esp idf
|
|
|
|
|
|
Add msc request sense callback
|
|
|
|
LUN1 of msc_disk_dual will be set to not ready to simulate medium not
present (e.g SD card removed)
|
|
set default error sense to NOT READY, Medium not present
|
|
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.
|
