If using a USB hub, a request outside the array size can occur
Original line:
ffb257ac17/src/portable/ohci/ohci.h (L162)
It can happen in a few places but one such example is here:
ffb257ac17/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.
So far tud_vendor_n_write() always flushed data.
It requires to have whole vendor packed constructed
before in one buffer.
With this change data do get flushed when endpoint size
is filled on write, when there is no enough data to
fill endpoint data is not sent and subsequent calls to
write functions can add more bytes.
Vendor code needs to call tud_vendor_n_flush() when packet is
ready to be sent.
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.
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.
