PANIC: ep 81 was already available

[ArjanteMarvelde]

Hello,
I have been struggling with getting a CDC and UAC2 device to run as part of my application on a Pico 1. The CDC part is working, and I have stdio using it, so I can see output. One of the outputs I get, when I try to do anything with the UAC2 device from e.g. windows control panel, is a TinyUSB PANIC message saying:
ep 81 was already available

So I am trying to figure out what this means, so I can find the root cause, assuming it is not a bug in the library.
Funny thing is that there should not even be an endpoint with that number, I think the usb_descriptors.c file should take the branch:

#else
  #define EPNUM_AUDIO_IN    0x01
  #define EPNUM_AUDIO_OUT   0x01

  #define EPNUM_CDC_NOTIF   0x83
  #define EPNUM_CDC_OUT     0x04
  #define EPNUM_CDC_IN      0x84
#endif

Any help would be much appreciated!

. . . Arjan

[HiFiPhile]

Likely #3397

[ArjanteMarvelde]

Okay, I have seen those issues. I have updated TinyUSB to 0.20, but the same happens.

For the record: my question is why I get this message and also why it refers to EP 0x81 while this is not what is (should be) in use.

[HiFiPhile]

Maybe there is a | 0x80 in your descriptor like:

tinyusb/examples/device/cdc_uac2/src/usb_descriptors.c

Line 125 in 723e016

TUD_AUDIO_HEADSET_STEREO_DESCRIPTOR(2, EPNUM_AUDIO_OUT, EPNUM_AUDIO_IN | 0x80),

[ArjanteMarvelde]

Indeed, thanks.
So that answers the second question, but I still don't understand the reason for this panic and error message.
The piece of code it panics on is in rp2040_usb.c:

      if (*ep->buffer_control & USB_BUF_CTRL_AVAIL) {
        panic("ep %02X was already available", ep->ep_addr);
      }

But I don't see where or why USB_BUF_CTRL_AVAIL was set.

[ArjanteMarvelde]

Okay, digging a little deeper.
In the rp2040 datasheet sect 4.1.2.5.1 there is a bit on how dual access to the DPSRAM is to be used; the processor sets the AVAILABLE bit to 1 to hands the buffer over to the usb-controller and v.v. the usb-controller resets the bit to 0 to hand it back.

There is an implicit setting of the bit in de function prepare_ep_buffer():
uint32_t buf_ctrl = buflen | USB_BUF_CTRL_AVAIL;
which seems logical.

The PANIC happens in the function _hw_endpoint_buffer_control_update32().
I don't understand why the non-PANIC branch of this function resets the bit to 0. Just before it was already tested to be 0, and in general the usb-controller should do this.
Again, no clue from where and why this function is invoked. Not a lot of comments in the code...