Support for AVR DU

[echoromeo]

Hi, I have added support for the new AVR DU Family, ported from the current XMEGA support, and added the AVR64DU32 Curiosity Nano board. I think the only thing I have not touched (yet) is bootloader.
I added it as ARCH_AVRDX in case more Dx USB devices pop up.

As I could not see any obvious DFP support in the build system I ended up including paths to the include file and device-specs file to the build flags in the makefile(s). Using the default Microchip Studio path in windows it would look like this:

CC_FLAGS += -B"C:/PROGRA~2/Atmel/Studio/7.0/packs/atmel/AVR-Dx_DFP/2.4.286/gcc/dev/avr64du32" -I"C:/PROGRA~2/Atmel/Studio/7.0/packs/atmel/AVR-Dx_DFP/2.4.286/include"
LD_FLAGS += -B"C:/PROGRA~2/Atmel/Studio/7.0/packs/atmel/AVR-Dx_DFP/2.4.286/gcc/dev/avr64du32"

Please have a look and let me know if this is something you would want to merge :)

[bradanlane]

We are interested in testing this PR against the Microchip "generated" stack (which is pretty heavy).

[echoromeo]

@bradanlane please go ahead and test it out and let me know if you have any questions or bugs/problems

[bradanlane]

@echoromeo ...

@bradanlane please go ahead and test it out and let me know if you have any questions or bugs/problems

I am sure the build process is not overly complex for anyone who has build it in the past. Unfortunately we spend about an hour trying to get through all of the generated errors (likely all due to configuration of the build environment).

Is there an example of setting up the USBtoSerial project for the AVR DU Curiosity Nano? (we have one of these for testing) ... specifically what changes are made to various .mk files to get the MCU, ARCH, BOARD, etc correct?

Here are some example issues which may help you understand where our configuration is incorrect:

• in the USBtoSerial Makefile, we set the above values to avr64du32, AVRDX, and AVR64DU32_CNANO respectively
• the make renders a large number of errors including:
  • undeclared such as TXEN1, UCSR1B, and UDR1
  • argument mismatch for Serial_SendByte
  • conflicting type for CALLBACK_USB_GetDescriptor

Addendum: I am using the features/avr-dx branch

[bradanlane]

@echoromeo ... much progress

I switched from attempting Projects/USBtoSerial to using Demos/Device/ClassDriver/VirtualSerial.

After adding the required CC_FLAGS+= and LD_FLAGS+= (described at the start of this PR) I received only one error.
The error RAMPZ used in ClockManagement.c. There is no definition of this value ... at least not when using avr_gcc version 7.3.0 and the AVR-Dx_DFP version 2.7.321

Solution: eliminating AVRDXCLK_CCP_Write and using CPU_CCP = CCP_IOREG_gc; // unlock protected register solves the issue and the Demo code works.

[bradanlane]

I have incorporated the code from this PR into a test project and it is working well at both 12mHz and 24mHz.

Thank you @echoromeo !

[WestfW]

It bothers me a bit to have so much volume of the changes be of the form

	#elif (ARCH == ARCH_AVRDX)
        // same defines/etc as in ARCH == ARCH_XMEGA

instead of doing

	#elif ((ARCH == ARCH_XMEGA) || (ARCH == ARCH_AVRDX))

Or somehow factoring out the DU as a subset of XMEGA (Haven't checked yet how possible that is...)
OTOH, I'm not familiar enough to the LUFA code or its implicit "style manual" to know whether that sort of thing is forbidden. :-(

[echoromeo]

The error RAMPZ used in ClockManagement.c. There is no definition of this value ... at least not when using avr_gcc version 7.3.0 and the AVR-Dx_DFP version 2.7.321

Solution: eliminating AVRDXCLK_CCP_Write and using CPU_CCP = CCP_IOREG_gc; // unlock protected register solves the issue and the Demo code works.

Ah, I suspect the RAMPZ was removed with a later DFP than the one I used. Will have a look and update the assembly in AVRDXCLK_CCP_Write.

It bothers me a bit to have so much volume of the changes be of the form

	#elif (ARCH == ARCH_AVRDX)
        // same defines/etc as in ARCH == ARCH_XMEGA

instead of doing

	#elif ((ARCH == ARCH_XMEGA) || (ARCH == ARCH_AVRDX))

Or somehow factoring out the DU as a subset of XMEGA (Haven't checked yet how possible that is...) OTOH, I'm not familiar enough to the LUFA code or its implicit "style manual" to know whether that sort of thing is forbidden. :-(

I believe you are reffering to the LUFAConfig.h files in all the LowLevel and ClassDriver folders. I agree that there is a lot of overlap. However, if you look at the original files you see there are a lot of the same defines/etc between

	#if (ARCH == ARCH_AVR8)

and

	#elif (ARCH == ARCH_XMEGA)

as well so I just tried to follow the same style. There are settings in there that probably can be moved out of the entire #if.

In the common files further down I have done as you suggested.

[WestfW]

I haven't looked carefully, but I have to ask:
Does adding a new chip family really require changes to 145 files, or is there some less dramatic way of doing things?

[vobsch]

Hi echoromeo,
thanks for sharing your modifications of LUFA code for adding support of the avr-DU family!
Your work was very helpful for me!

When trying to port LUFA USBtoSerial project to the avr32DU14 MCU, I noticed that the EVENT_CDC_Device_LineEncodingChanged() delivers wrong data in the variable
CDCInterfaceInfo->State.LineEncoding.

The reason is probably an incompatibility between the USB interfaces of ATxmega and AVR-Du, as mentioned in Section 28.3.2.2. of AVR32/16DU14/20/28/32 Complete Data Sheet DS40002576 (last paragraph):
"Control transfers use the endpoint buffers differently from In and Out endpoints. The data packet in the Setup stage is stored in the endpoint's OUT data buffer, while data packets in the Data stage (i.e., IN or OUT) are stored in the IN data buffer. In other words, EP[n].OUT.DATAPTR points to the received Setup stage packet and EP[n].IN.DATAPTR points to data to be transmitted or received in the Data stage."

I fixed the problem with a small modification in LUFA/Drivers/USB/Class/Device/CDCClassDevice.c:
CDC_Device_ProcessControlRequest() now reads from IN-Endpoint when handling an USB_ControlRequest.bRequest on a AVR-DU MCU, see attached patch (pls. notice that I'm neither an USB nor a LUFA expert).

The patch also adds 'AVR_AVR32DU14' in LUFA/Drivers/USB/Core/USBMode.h, fixes errors in
LUFA/Drivers/Board/Joystick.h and LUFA/Drivers/Board/Buttons.h when compiling for BOARD = NONE and
LUFA/Platform/AVRDX/ClockManagement.h now uses CPU_CCP = CCP_IOREG_gc; when RAMPZ is not defined by io.h, as it happens when using a recent avr-libc.

Regards,
Volker

lufa-feature-avr-dx.patch