ISO packet size is up to 1023 for full speed device.
Upon completion of ISO reception, reported length of incoming packet
was truncated to one byte only.
This results in incorrect data stream for higher bit rates
48 samples * 4 bytes per sample * 2 channels = 384 bytes of data
and 128 was reported.
There is no change in logic extending xact_len to uint16_t fixes the issue.
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.
This PR fixes a transmit lock-up, which happens, when data is received
and sent at the sime time at moderate to high speeds, like code
which just echoes incoming data.
In my case, an issue was reported here:
https://github.com/micropython/micropython/issues/8521
since HS interrupt endpoint can be up to 1024, 8-bit is not enough.
affected APIs are:
- tud_hid_n_report() / tud_hid_report()
- tud_hid_report_complete_cb()
kkitayam