Skip to content

Conversation

@tmon-nordic
Copy link
Contributor

No description provided.

tmon-nordic and others added 8 commits July 30, 2025 08:12
…e data

Stop processing microphone data on error or when streaming ends. This
avoids I2S read timeouts due to audio data not being available while
streaming.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit 943fc6f)
This commit resolves a bug where the USB Endpoint
provided by the HID driver was incorrect when in
High Speed mode.

Signed-off-by: Victor Brzeski <[email protected]>
(cherry picked from commit c0e1268)
Signed-off-by: Tomasz Moń <[email protected]>
Change the macros to have only one plus operator per term. This is
purely stylistic change, no functional changes.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit 673f324)
…ndpoints

Enable double buffering on data OUT endpoints to allow USB stack to
enqueue next transfer as soon as possible. This is especially useful
when operating at High-Speed where there is significantly less time
between subsequent SOF packets.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit 2f343bf)
…nqueue

Release receive buffer on failed endpoint enqueue.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit f9ac318)
…ndpoint

Enable double buffering on isochronous feedback endpoint to avoid
sending ZLP instead of feedback information.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit 223d23a)
…ing incompisoout

Rearm isochronous endpoints when handling incomplete iso out interrupt
to make it possible to rearm the endpoint in time (before SOF),
especially when operating at High-Speed.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit 6eb2fa8)
Incomplete iso IN/OUT is just informative and its occurrence does not
prevent the endpoint from actually transmitting/receiving data. Such
"late" isochronous transfers, which are perfectly fine according to USB
specification, were observed on Windows host with nRF54H20 running
explicit feedback sample operating at High-Speed.

The incorrect handling manifested itself with "ISO RX buffer too small"
error message. The faulty scenario was:
  * incompISOIN handler does not find any matching endpoint
  * incompISOOUT handler disables endpoint, discards buffer and sets
    rearm flag
  * next DWC2 interrupt handler iteration after reading GINTSTS
  * XferCompl interrupt on iso IN endpoint
  * XferCompl interrupt on iso OUT endpoint
      - transfer was actually happening to the buffer discarded in
	incompISOOUT handler
      - XferCompl handler modified the next buffer
  * GOUTNakEff interrupt, iso OUT endpoint EPDIS bit is set
  * EPDisbld interrupt, rearm flag set
      - the buffer modified by XferCompl is used and fails because it is
	not large enough

Modify the sequence so it accounts for host actions and the above faulty
scenario no longer causes any problems.

Signed-off-by: Tomasz Moń <[email protected]>
(cherry picked from commit 8d1f7b3)
@tmon-nordic tmon-nordic merged commit 1e6c549 into nrfconnect:main Jul 30, 2025
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants