Problem with CDC ACM multiple transfers in one interrupt

[Abraham Hamidi]

I created a protocol for packets through CDC ACM, and I send multiple packets if the length goes above 64 bytes. Sometimes I send "request" packets that are received by the nrf52840, so the nrf52840 will receive like 12 requests for data at a time, so I have 12 irq_tx_enable rounds where it sends queued data from a ringbuffer, all in the same interrupt. However, if I don't put an artificial delay between request packets, it fails to send all 12. It will silently fail at around the 5th and move on. Is there an elegant solution to this, without a separate thread to make sure irq_tx_enable happens slowly?

[Kenneth]

Hello,

It's not entirely clear if these are IN or OUT transactions, but it should be explained how this should be handled in the USBD peripheral:
https://infocenter.nordicsemi.com/topic/ps_nrf52840/usbd.html 

For instance I can find Events it says:

"Events ENDEPIN[n], ENDEPOUT[n] (n=0..7), ENDISOIN, and ENDISOOUT events indicate that the entire buffer has been consumed. The buffer can be accessed safely by the software.

Only a single EasyDMA transfer can take place in USBD at any time. Software must ensure that tasks STARTEPIN[n] (n=0..7), STARTISOIN , STARTEPOUT[n] (n=0..7), or STARTISOOUT are not triggered before events ENDEPIN[n] (n=0..7), ENDISOIN, ENDEPOUT[n] (n=0..7), or ENDISOOUT are received from an on-going transfer."

All that said, I am not sure how low level you are working here, but I would assume these details were abstraced away if you were using the driver / library.

Best regards,
Kenneth

[Abraham Hamidi]

Yeah, I'm doing very similarly to this sample: https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/usb/cdc_acm

Do you know if any of that can be abstracted through zephyr, interrupt based like the sample?

[Kenneth]

That example should be safe to use, since the interrupt_handler() callback handler will be called each time new data can be read/written. It's not possible to put a while loop in the interrupt_handler() callback, but it should work as-is if you just feed new data once every interrupt_handler() callback is called.

Kenneth

[Abraham Hamidi]

Yeah, so the problem is when I have multiple calls to irq_tx_enable in the interrupt. At some point it just drops data when writing for like the 6th time in the same interrupt service routine

[Abraham Hamidi]

Unfortunately, I can't reproduce the problem anymore. It seems to have magically gone away. I'll open this again if I run into the problem again with more details.