USB freezes when sending data from UDI_CDC_RX_NOTIFY

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I hope this information can be useful to other developers.
This information applies to USB CDC driver found in ASF. I experienced the issue with release 3.8.1.
As you know, ASF allows you to define callback functions for various USB events. One of them is UDI_CDC_RX_NOTIFY, called when new data arrives from the USB.

If you attempt to send too much data while executing that callback function, the USB driver freezes.
"Too much" depends from the size of the USB TX buffer, defined in udi_cdc.c

COMPILER_WORD_ALIGNED static uint8_t udi_cdc_tx_buf[UDI_CDC_PORT_NB][2][UDI_CDC_TX_BUFFERS];

gives you a limited control over the buffer size. Normally UDI_CDC_TX_BUFFERS is 1, and this gives you 64*2*1 = 128 bytes.

If you comment out

#define UDI_CDC_LOW_RATE

Then the buffer becomes 64*2*5 = 640 bytes.

If you need to send more data, then you have to manually modify udi_cdc.c

In my opinion, this is a design mistake, but after a long ping-pong of messages, Atmel Support still insists this is a "normal" behaviour.
I wonder if this happens with LUFA as well :roll:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

2 questions:

1. are you aware that this callback runs in interrupt context?
2. do you check uhi_cdc_is_tx_ready() before you send out data?

-sb

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Sambrown,

Answers are yes, and yes.

I am 100% sure that the problem is related to the callback function running as ISR. For this problem, it seems that the only remedy is increasing the buffer size so it can contain all the data you need to send.
As an alternated method, instead of sending the data in place, I schedule an event that is executed outside the callback.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kalbun wrote:

As an alternated method, instead of sending the data in place, I schedule an event that is executed outside the callback.

good idea :wink:
-sb