Bug 2910 - USB Composite Device CDC and MSC endpoint allocation in High Speed mode
: USB Composite Device CDC and MSC endpoint allocation in High Speed mode
Status: CLOSED INVALID
Product: Atmel Software Framework
avr32
: v3.4.x
: All Standalone
: normal priority normal (vote)
: ---
Assigned To: ASF Maintainers
:
:
:
:
  Show dependency treegraph
 
Reported: 2012-11-01 14:09 CET by Viktor Bachraty
Modified: 2012-11-13 08:44 CET (History)
2 users (show)

See Also:
Public Description:
Development Branch:
Whiteboard:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Viktor Bachraty 2012-11-01 14:09:29 CET
If you enable HiSpeed support in the Composite device by defining

conf_usb.h:
#define  USB_DEVICE_HS_SUPPORT

the configuration of the device will fail in High Speed mode. The reason is a
failed endpoint allocation, because both MSC and CDC drivers are trying to
maximize the usage of the DPRAM:

udi_cdc.h:
#define UDI_CDC_DATA_EPS_HS_SIZE    512

udi_msc.h:
#define UDI_MSC_EPS_SIZE_HS   512

Both drivers try to allocate 2 banks each of 512 bytes per endpoint which is 
2(banks) x 2(endpoints) x 2(drivers) x 512 = 4096 bytes + 64 bytes for the
control endpoint. That is more than the DPRAM size (2368 bytes according to the
datasheet). The device will work in Full Speed mode though (in that case all
buffers are set to 64 bytes)
Comment 1 Stephane Mainchain 2012-11-06 16:33:46 CET
Thanks for reporting, we will look into that.
Comment 2 Sylvain Guyon 2012-11-12 16:36:23 CET
Note: The bulk endpoints in high speed must be equal to 512B to be USB
compliance.

The ASF USB cannot able to see the DPRAM error allocation during compilation.
However, the allocation error is catch during execution thank to an Assert()
macro.

The AT32UC3A3 is support the composite device MSC/CDC, however the USB bulk
banks must be reduce to a single bank.

The patch is to add the following define in conf_usb.h:
#define  UDD_BULK_NB_BANK(ep) (1)
Comment 3 Viktor Bachraty 2012-11-12 18:12:56 CET
(In reply to comment #2)
> Note: The bulk endpoints in high speed must be equal to 512B to be USB
> compliance.
> 
> The ASF USB cannot able to see the DPRAM error allocation during compilation.
> However, the allocation error is catch during execution thank to an Assert()
> macro.
> 
> The AT32UC3A3 is support the composite device MSC/CDC, however the USB bulk
> banks must be reduce to a single bank.
> 
> The patch is to add the following define in conf_usb.h:
> #define  UDD_BULK_NB_BANK(ep) (1)

Thanks for the explanation. I'll fix my code with your proposal of using a
single bank instead of two, because until now I have used a smaller buffer
size.

However, I do not agree that the ASF code can't be aware of the DPRAM size.
Many things are defined in the form of per processor constants in the header
files. The example is obviously misconfigured, and the compiler should give at
least a warning if not an error. The Assert() is an ugly solution, because it
requires to debug the code for everyone who starts working with it (without a
debugger it's very difficult to track this problem down), especially
considering the fact that the issue of DPRAM allocation is not mentioned in the
configuration headers (conf_usb.h) nor the app notes.

I would suggest something similar to this solution:

// in some UC3Ax specific header
#define DPRAM_SIZE 2368

// in udi_composite_conf.h (this file is empty anyway)
#ifdef USB_HIGHSPEED

// make a check on buffer all buffer sizes
#if USB_DEVICE_EP_CTRL_SIZE + ((USB_DEVICE_MAX_EP-1) * 512 * 2) > DPRAM_SIZE
#error "USB endpoint buffers misconfigured:
#endif

#endif

I expect the original intention was to use a separate size and bank count for
each endpoint, otherwise the "ep" parameter in the UDD_BULK_NB_BANK macro
doesn't make much sense. That way the check on the sum size would be quite
straightforward.
Comment 4 Sylvain Guyon 2012-11-13 08:44:06 CET
> However, I do not agree that the ASF code can't be aware of the DPRAM size.
Your feedback has been registered (Atmel internal reference ASFP-3124), and we
will work to find a solution to detect the error at the compilation.