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.
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.
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.
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.
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.
Allwinner F1Cx00s family is a series of SoCs
with Mentor MUSB controller and HS phy. It comes
with a slightly different register space layout,
and some quirks, so it's not multiplexed with
the existing musb support library.
This library currently requires to be compiled
with https://github.com/hongxuyao/F1C100s_with_Keil_RTX4_emWin5
Bluetooth's specification defines IAD for primary controller.
While it seems that Windows and Linux can leave without this,
there is no reason TinyUSB should not provide it.
Two interfaces that are required by Bluetooth Primary Controller
do not have IAD according to Bluetooth specification.
Those two interfaces were opened separately in process_set_config().
Later interface association was inferred for BTH (along with other
drivers), since then only one call to open() is place for BTH driver
that should prepare both interfaces at once.
To make it work again btd_open() parses two interfaces at once.
dcd_synopsys.c included broadcom/interrupts.h before
preprocessor check whether file should be used.
Since mynewt build does not include all folders it resulted in build
error.
Now offending include is moved few lines after preprocessor check.
USB3CV tool verifies MSC device by sending too short or
too long packets.
In case of too long packets (msc_device requested 31 bytes
but incoming data had 32 bytes) extra byte(s) were left in
FIFO resulting in some data mismatch later on.
Now if more data is received in packet that expected extra
bytes are just dropped.
Normal TX handler for IN non-0 endpoints is called during
outgoing transfer or just after it was finished.
It may need to fill TX fifo with same data if TX_DONE is present
but ACK_STAT is not.
It may need to fill more data when called during transfer.
But it may also be called when STALL was sent.
In this case TX_DONE is set ACK_STAT is not, just like for packets
that were sent but no ACK was received.
Code was trying to send something again. There was nothing to send
so empty ZLP was scheduled for stalled endpoint.
This ZLP was later send to host where valid response was required.
This change checks if notification was for STALL endpoint and
does not try to fill TX FIFO in that case.
- physically suppress warnings in TinyUSB headers using pragmas so they don't break -Werror compilation of external files that include them
- fix compiler warnings in rp2040 port
- add cmake method to rp2040 port to allow an external project to suppress warnings in TinyUSB itself
Add FT90X and FT93X to the list of devices in tusb_option.h. 1700 for FT90x and 1701 for FT93x.
Set endpoint attributes for FT90x and FT93x in dcd_attr.h.
Add FT90x routines for USB device in src/portable/bridgetek/ft90x/dcd_ft90x.c
The location for hardware header files and libraries is hw/mcu/bridgetek/ft90x/hardware. There are no files in the repository, but files will be linked as a submodule in the future. The required files can be copied from or linked to the location "C:/Program Files(x86)/Bridgetek/FT9xx Toolchain/Toolchain/hardware" once the toolchain is installed.
Makefile for the MM900EV1B board for developing with an FT900 device is present. Use "BOARD=mm900ev1b".
Windows and Linux host during enumeration requests device
descriptor with request size set to 64 bytes when device
was in default state (no address).
Those systems do not want 64 bytes though since usb descriptors is
only 18 bytes long so they silently expect that only one packet
will be received possibly 18 bytes for EPS > 16 or 8 or 16 bytes
for smaller EP0.
For devices with CFG_TUD_ENDPOINT0_SIZE size 8 or 16 there was
workaround that reduced request size to CFG_TUD_ENDPOINT0_SIZE
and that was enough to satisfy Windows and Linux hosts.
However USBCV testing application also requests device descriptor
but with size set to 18 bytes. Workaround for Window/Linux
prevented USBVC to tests devices with 8 bytes EP0 size since it
send only 8 bytes while application did wanted 18 bytes.
Solution that satisfies both cases it to check if in default state device
descriptor request wants more bytes than descriptor size (18).
If so host is expecting to receive less bytes then requested
and workaround would be applied since Linux/Windows only try
to read one packet.
If 18 bytes was requested as is the case for USBCV, core returns
descriptor in 2 or 3 packets as application expects.
Note: this commit does not change any logic.
xfer_ctl_t structure keeps all dynamic data connected with transfer.
It used to have pointer to register set that was constant and was there
for convenience only.
Removing register pointer from structure makes cleanup easier as whole
structure can be erased with memset like function.
In many cases functions were using local variable regs and xfer->regs which
were same, that could be confusing so this part is unified.
Few macros were added for easy conversion between epnum, xfer, and regs.
So far bus reset was handled (with some holes in it).
Sleep and remote wakeup were not really tested and did not work.
With this change:
- bus reset is reworked
- remote wakeup works
- bus signal sleep is handled
DA146xx are Bluetooth devices that may be battery
powered and when not connected to USB host there
is no need for USB peripheral to be running.
This change allows to enable USB peripheral when
VBUS is present otherwise USB is down reducing
power consumption.
tud_vsub_changed() function must be called
whenever VBUS change was detected.
For bus-powered devices this function should be called
at startup since VBUS must be present while device
is working.