Field started (regardind transfer) was only cleaed when transfer
was finished.
For audio devices set interface is called many times.
When there is no audio (silence) set interface requests zero
lenght bandwithd that in turn calls dcd_edpt_close().
When endpoint is closed due to set interface request transfer
should not longer be started since it will block next start transfer
with assert.
This just sets 'started' to false when endpoint is closed.
dfu_moded_open() only works correct when its called on DFU interface
descriptor. It means that DFU is the only one interface in configuration
or driver is called after all others interface drivers were tried and
gave up.
If other interface is supported and but driver for DFU is called first
(this is the case for BTH and RNDIS).
Code after while loop (that was not entered) has an TU_ASSERT that will
make set_configuration to fail.
Now TU_VERIFY is called first to make sure open code is called for DFU
only and not other interface descriptors like in other drivers.
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.
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.
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.
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.
USB3CV tool complains about too short serial number being used
in MSC device.
This just extends serial number to 12 characters, it makes it
easier to analyze USB3CV logs where this unnecessary warning
made output red.
Offending warning:
Serial Number string for MSC device : iSerialNumber = 0x3
Checking iSerialNumber String Descriptor: index = 0x03.
String Descriptor : "123456". (ENGLISH_US)
Using Language ID 0x409
MSC Serial Number length = 14
Invalid MSC Serial Number length : should be >= 26
*************************
Invalid MSC Serial Number length
*************************
*************************
(MSC: 5.1.2) Serial number must be a string, 12 characters or longer
(if the device supports a BOT interface, bInterfaceProtocol = 0x50),
or exactly 12 characters long (if the device supports a CBI interface,
bInterfaceProtocol = 0x00 or 0x01, and has a serial number).
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.
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
Two BSPs with DA146xx MCUs are now adopted to
VBUS handling changed introduced to dcd_da146xx driver.
da14695_dk_usb as bus-powered devices informs driver that
VBUS is present at startup.
da1469x-dk-pro has VBUS change interrupt handler that
informs driver about VBUS changes.
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.
For self powered device if device started without VBUS present
it would not be correctly attached to USB bus even if tusb_vbus_changed()
was later called.
This modifies dcd_init() so it starts USB state machine without checking
if VBUS is present or not, like all others drivers do.
tusb_vbus_changed() function is also removed its content was moved to dcd_init.
Errata code referred to NRF_USBD_BASE.
This definition is not present in NRF5340 but both NRF52 and NRF53
do have NRF_USBD which maps to NRF_USBD_BASE for NRF52 and
to NRF_USBD_S_BASE for NRF5340.
This just make build possible for NRF5340.
ep_in_as_intf_num was incorrectly used to access out interface
which is defined for 'in' interface.
Code related to 'out' endpoint should use ep_out_as_intf_num instead.
This example code creates USB Audio 2.0 headset device.
Device has two audio interfaces first stereo speaker
with 48kHz stereo stream.
Second interface for microphone with 48kHz mono stream.
This example can be used to start working on audio device.
It can be also used to verify ISO endpoints for boards.
Speaker adaptive clock (bound to SOF).
Microphone for now has asynchronous clock.
Volume and mute control while present are not used for data stream
modification.
Feature unit descriptor size depends on number of channels.
So far only single channel feature unit was present.
This change adds feature unit descriptor for two channels.
OSAL_QUEUE_DEF was not updated while FIFO was changed
to use unmasked pointers.
Two fields that are crucial to new functionality were left
uninitialized resulting in FIFO slowing down in time.
FIFO is limited to 64 bytes yet MCU is capable of transmitting
larger packets provided that FIFO will be filled on the fly
and USB_USB_TXCx_REG_USB_LAST_Msk bit is set after FIFO is
filled with all the data that should be transmitted.
This change allows to use FIFO level warning interrupt to fill
FIFO. When DMA is available it will be used instead of interrupts.
Some function names were changed to better reflect what each function
does.
Closing endpoints can be important when there are alternate
instances. This adds functionality of closing endpoints
similar to what exists in other drivers.
Internal FIFO for each endpoint is limited to 64 bytes.
It is possible to have longer packets if respective FIFO
is read during actual packet transmission.
This change updates receive data path to allow packets (and
endpoint size) larger then 64 bytes.
If DMA is not used yet DMA is setup for reception of big packets.
If DMA is already assigned to some transfer, code enables FIFO level
warning interrupts and tries to read data before FIFO is filled up.
ISO endpoints were not covered so far by the driver code.
This adds support for ISO IN and OUT endpoint handling.
Registers for ISO IN(OUT) endpoints are placed just after normal IN(OUT)
so in some cases common code could be used for handling all type of
transfers.
Generally code synchronizes ISO endpoint handling to SOF interrupt.
This code does not change the way of how non-ISO endpoints are treated.
Code uses strategy outlined in nRF52840 Produce Specification v1.0
sections 6.35.11.1 and 6.35.11.2.
Closing endpoints can be important when there are alternate
instances. This adds functionality of closing endpoints
similar to what exists in other drivers.
Currently number of endpoints was hard coded to 8.
NRF52 has 9 IN and 9 OUT endpoints.
ISO endpoints are 0x08 and 0x88 and without this change those
two ISO endpoint could not be used.
Current implementation always sets odd/even bit for ISO transactions.
This is a good strategy only if interval is 1.
For ISO endpoint interval in (micro)frames is computed as
2^(interval-1), which means that odd/frame number should stay
same for interval values > 1.
With this change only when interval is 1 odd/even bit is modified.
dcd_edpt_close() no longer modifies FIFO distribution.
Code that that was commented out is removed along with
variables that are no longer used.
FIFO distribution among endpoints is handled upfront
and does not need to be modified in open and close endpoint
functions.
This allow to build with single FIFO for devices with multiple channels.
Having just one FIFO greatly reduces time needed to feed endpoint.
This change also allows to have one FIFO with 24 bit samples that
is not rounded up to 32 bit elements.
CFG_TUD_AUDIO_RX_ITEMSIZE and CFG_TUD_AUDIO_TX_ITEMSIZE can be manually
defined. This allows to use FIFO more efficiently when 24 bits samples
are already using 3 bytes, in this case there is no need to put them
into FIFO one by one.
For 8, 16, 32 bits samples size efficient FIFO access is always used
when single FIFO is selected.
This also changes FIFO element size to 1, FIFO usage was confusing
in some place it treated content as byte base in other it looked like
ITEM size is to be used. Also bufsize that in most (maybe all) cases
was really meaning item count.
bufsize now mean buffer size in bytes so there is no confusion.
Some API uses interface number as argument, some wants to have
rhport.
To accommodate need of rhport for functions that don't have it
rhport can be extracted from interface data.
Having just inline keyword for function specified in header
may not be enough to generate code for function.
Adding static solves this problem.
static inline is used in all other inline functions in TinyUSB.
Recommended FIFO allocation schema includes 2 maximum endpoint sizes.
Comment suggested that this is the case while it would work according
to this description only in checked endpoints were ascending sizes.
Also two same size endpoints would be counted as one.
That is fixed by way sz is filled.
Calculation used too much modulo operation while single division was enough
to account for odd FIFO sizes.
Extra space that is evenly distributed between Bulk and control endpoints
was incorrectly calculated it could prevent allocation of ISO endpoint FIFO
when bulk endpoints existed with smaller endpoint numbers.
Minimum endpoint FIFO size is 16 32bit words, FIFO space requirement is
now observed.
Operator < used in while condition was obviously incorrect.
Loop starts with checking if unsigned variable is less then 0.
This condition is always false.
This reverses condition to follow intention of of the code.
b_bytes_copied was pointer with NULL value instead of
plain variable.
NULL pointer was passed to audio_tx_done_cb() and dereference
as well.
Now variable is not a pointer.
Buffer for TX and RX FIFO was not taking into account
size of element leading to out of bound access.
audio_tx_done_type_I_pcm_ff_cb() reported copied bytes was not returning
correct value number if channels was omitted in computation.
Transfer size calculation uses simpler arithmetic.
In several place p_desc_end calculation was not taking into account
that starting pointer (_audiod_itf[idxDriver].p_desc) was pointing
past interface association descriptor.
It would result in accessing random memory.
Endpoint close was implemented only in one driver so far.
This function is needed for interfaces with several alternate settings.
The way FIFO is allocated in dcd_edpt_open() allows to correctly close
only one IN endpoint (the one that was opened last).
Wrong FIFO was flushed in dcd_edpt_stall().
(epnum - 1) should only be used when accessing DIEPTXF registers.
For DIEPCTL and GRSTCTL epnum is correct index.
For ISO endpoint driver has to specify when data
is to be transmitted (odd or even frame).
Currently code was not updating this bit resulting in
data being sent every other frame.
If interval was 1ms full data packed was sent every 2ms, and
ZLP was sent in between.
This adds source files that allow to run TinyUSB stack on DA1469x-dk-pro board.
Source files .c .S and .ld are taken from Apache Mynewt repository.
Those files were stripped to allow starting board without Mynewt os.
Dialog Semiconductor's BLE MCU DA1469x comes with full speed USB.
It's base on National Semiconductor discrete USB controller USBN9603/4.
This adds support for:
- control/interrupt/bulk endpoints (up to 64 bytes)
- ISO endpoint were not tested and may not work correctly
- reset/sleep/wakeup are handled
- code for VBUS changes is provided
For some reason bluetooth stack implementations send class requests
to device instead of interface.
To implement HCI interface over USB non device addressed requests
for class need to be handled.
For normal mynewt packages newt tool wants to have specific
folder structure. It wants to have src and include directories,
and only include (and arch related) directory is added to compiler
include search list.
Since TinyUSB has different folder structure newt tool will not
add anything to -I directives and those would need to be
specified as pkg.cflags: "-I@tinyusb/src"
Recent change to newt tool allowed to add specific include directories
for external (sdk) packages so just including package will add
necessary -I to build commands.
This commit changes package type to sdk and specifies src as include
root for TinyUSB.
For older newt tool adding sdk and include_dirs does not break build.
Code suggested that PLL with MSI is used resulting in 80MHz clock.
When in fact PLL was not configured and system clock was left at MSI 48MHz.
This happens because PLL configuration requires that SysTick interrupt
has interrupt priority level configured correctly.
As it seems ST code intentionally setups variable uwTickPrio to invalid
value and later when it is not setup by user code configuration
of oscillator will fail before PLL is configured.
This simple changes systick priority to some valid value that
allows clock to use PLL.
Field PLLState was not initialized in RCC_OscInitStruct.PLL in
function SystemClock_Config().
Value is used in HAL_RCC_OscConfig() regardless of oscillator.
In lucky case value would be 0 RCC_PLL_NONE and nothing would
happen.
If value was incorrect following line would end up in assert:
assert_param(IS_RCC_PLL(RCC_OscInitStruct->PLL.PLLState));
If value was valid but no RCC_PLL_NONE pll could be configured
with some other random values.
Setting PLLState to RCC_PLL_NONE eliminates potential problem.
Busy flag was set to true after call to dcd_edpt_xfer().
In some cased it was possible that transfer finished before function
ended.
In this case busy flag could be set to false before it was set to
true.
Then setting it to true after dcd_edpt_xfer() made edpoint busy forever.
This change marks endpoint as busy before transfer is started to
avoid race condition.
For IN endpoints output FIFO is filled in interrupt, therefor before
endpoint is enabled, DIEPTSIZ is set with correct size of packet.
Then endpoint is enabled and FIFO empty interrupt is enabled.
This works fine except for the ZLP. Enabling FIFO empty interrupt
results in interrupt handler being called all the time because
there is nothing to put in the FIFO.
Eventually it ends when IN token is received and empty
packed is transmitted out.
This change does not enable FIFO empty interrupt for ZLP reducing
CPU load.
Queue table has pointers instead of data os_event structs.
This resulted in crashes when elements were put to queue and
overwritten variables that were just after mpool desiged
for queue.
Jerzy Kasenberg