abcminiuser/lufa

LUFA - the Lightweight USB Framework for AVRs.

lufa's Issues

How does a configuration descriptor get associated with the main device descriptor?

I see that USB_Descriptor_Device_t has a field called NumberOfConfigurations, and I see the USB_Descriptor_Configuration_t stuct, but I'm not sure how I specify that a USB_Descriptor_Configuration_t belongs to a USB_Descriptor_Device_t.

Does the compiler or the running program somehow automatically associate NumberOfConfigurations USB_Descriptor_Configuration_ts with a USB_Descriptor_Device_t? If so, do they get associated in the order defined?

Maybe I just don't know enough about USB yet, but I was expecting USB_Descriptor_Device_t to contain USB_Descriptor_Configuration_ts (or an array of pointers to them).

Zeroes being blocked by virtual serial port

I'm doing binary transfers using the LUFA serial port. I can send 0x00 from the AVR to my PC via the USB serial port no problem but going the other way 0x00 get blocked, all other values seem to get through.
Have I got some configuration wrong or is it a bug? All advice gratefully received!

OUT endpoint for the XMega devices

I was reading from forums that making OUT endpint for HID class devices is a burden. I have XMega project where I am using generic HID device for sending and receiving up to 20 bytes of data telegrams. My controller is composite device including 3 different USB HID logical devices and using 4 endpoints. One of the logical devices needs OUT endpoint. So, I invested some time to implement possibility to have also OUT endpoint available fro HID class device.

The feature can be turned on in Config/LUFAConfig.h with

    #elif (ARCH == ARCH_XMEGA)
        #define HID_HAVE_OUT_ENDPOINT

It is implemented only for XMEGA in this diff. Without the define it works as before.

The xmega controller USB hardware is haveing register for reading out how many bytes was sent in the OUT transfer, the mega ones seem not to have it. When dealing with telegrams and not with streams, the amount of bytes is not a big problem, as telegram needs to have protocol for reading and handling of the contents.

It seems I can not attach the patch but must include in this description, UPS and it seems to be reverse.

diff -r 8e76cf8ff108 -r 5b1ce1d1573c Drivers/USB/Class/Device/HIDClassDevice.c
--- a/Drivers/USB/Class/Device/HIDClassDevice.c Mon May 12 16:00:37 2014 +0300
+++ b/Drivers/USB/Class/Device/HIDClassDevice.c Thu May 01 20:16:51 2014 +0300
@@ -145,10 +145,6 @@

    if (!(Endpoint_ConfigureEndpointTable(&HIDInterfaceInfo->Config.ReportINEndpoint, 1)))
      return false;
-#ifdef HID_HAVE_OUT_ENDPOINT
-   if (!(Endpoint_ConfigureEndpointTable(&HIDInterfaceInfo->Config.ReportOUTEndpoint, 1)))
-     return false;
-#endif

    return true;
 }
@@ -205,41 +201,6 @@

        HIDInterfaceInfo->State.PrevFrameNum = USB_Device_GetFrameNumber();
    }
-
-#ifdef HID_HAVE_OUT_ENDPOINT
-   bool CALLBACK_HID_Device_ProcessHIDoutReport( USB_ClassInfo_HID_Device_t* const HIDInterfaceInfo,
-           const void* ReportData,
-           const uint16_t ReportSize );
-
-   if( HIDInterfaceInfo->Config.ReportOUTEndpoint.Address != 0 )
-   {
-       Endpoint_SelectEndpoint(HIDInterfaceInfo->Config.ReportOUTEndpoint.Address);
-
-       /* Check to see if a packet has been sent from the host */
-       if (Endpoint_IsOUTReceived())
-       {
-           uint8_t* ReportData = HIDInterfaceInfo->Config.ReportOUTBuffer;
-           uint16_t ReportSize = 0;
-
-           while ( Endpoint_IsReadWriteAllowed()  )
-           {
-               uint8_t b = Endpoint_Read_8();
-               if( ReportSize < HIDInterfaceInfo->Config.ReportOUTBufferSize )
-               {
-                   // avoid over filling of the buffer
-                   *ReportData = b;
-                   ReportSize++;
-                   ReportData++;
-               }
-           }
-
-           /* Process Report Data */
-           if( CALLBACK_HID_Device_ProcessHIDoutReport( HIDInterfaceInfo, ReportData, ReportSize ) )
-               Endpoint_ClearOUT();
-       }
-   }
-
-#endif
 }

 #endif
diff -r 8e76cf8ff108 -r 5b1ce1d1573c Drivers/USB/Class/Device/HIDClassDevice.h
--- a/Drivers/USB/Class/Device/HIDClassDevice.h Mon May 12 16:00:37 2014 +0300
+++ b/Drivers/USB/Class/Device/HIDClassDevice.h Thu May 01 20:16:51 2014 +0300
@@ -86,11 +86,6 @@
                    uint8_t  InterfaceNumber; /**< Interface number of the HID interface within the device. */

                    USB_Endpoint_Table_t ReportINEndpoint; /**< Data IN HID report endpoint configuration table. */
-#ifdef HID_HAVE_OUT_ENDPOINT
-                   USB_Endpoint_Table_t ReportOUTEndpoint; /**< Data OUT HID report endpoint configuration table. */
-                   void*    ReportOUTBuffer;     /**< Pointer to the reserved memory for out report buffer */
-                   uint8_t  ReportOUTBufferSize; /**< Size of the out report buffer. This amount of bytes will be filled from USB device */
-#endif // HID_HAVE_OUT_ENDPOINT

                    void*    PrevReportINBuffer; /**< Pointer to a buffer where the previously created HID input report can be
                                                  *  stored by the driver, for comparison purposes to detect report changes that

Weird issues with LUFA on macOS (sierra and yosemite)

I'm using LUFA for my own multi-mcu/cross-platform bootloader that is using that HID trick to bypass windows signing once more and ran into a very weird issue:

• In macOS on a real mac with usb3.0 IOHIDDeviceSetReport seems to fail randomly, returning -536870163 or -536850432 when it fails.
• On a hackintosh laptop that is my usual testing rig for mac builds everything works with usb 3.0 ports (Those ports are using opensource, non-apple GenericUSBXHCI.kext driver), but when plugged into usb 2.0 ports that are handled by the apple driver same thing as on a real mac happens.
• The same bootloader (e.g. using the same spec and descriptors) when compiled for a different avr using vusb seems to work with apple's usb driver with no issues, so I really think it might be a lufa proplem.

The bootloader userspace tools are here: https://github.com/uISP/uHID-userspace
The bootloader itself (lufa and v-usb stacks): https://github.com/uISP/uHID-bootloader-avr

The same code works with no problems on the same hardware under windows, linux (hidraw and libusb alike) and freebsd, only mac is giving me pain (
Any idea where to start looking for the bug?

Low Level AudioOutput demo fails to set audio parameters

Bug report from a user. The LowLevel AudioOutput demo fails to set the requested audio parameters:

# aplay -v -D front:CARD=Demo,DEV=0 /usr/share/sounds/alsa/test.wav
Playing WAVE '/usr/share/sounds/alsa/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
aplay: set_params:1297: Unable to install hw params:
ACCESS:  RW_INTERLEAVED
FORMAT:  S16_LE
SUBFORMAT:  STD
SAMPLE_BITS: 16
FRAME_BITS: 32
CHANNELS: 2
RATE: 44100
PERIOD_TIME: (125011 125012)
PERIOD_SIZE: 5513
PERIOD_BYTES: 22052
PERIODS: (3 4)
BUFFER_TIME: 500000
BUFFER_SIZE: 22050
BUFFER_BYTES: 88200
TICK_TIME: 0

The ClassDriver, on the contrary, says:

# aplay -v -D front:CARD=Demo,DEV=0 /usr/share/sounds/alsa/test.wav
Playing WAVE '/usr/share/sounds/alsa/test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Hardware PCM card 3 'LUFA Audio Out Demo' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 22050
  period_size  : 5513
  period_time  : 125011
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 5513
  period_event : 0
  start_threshold  : 22050
  stop_threshold   : 22050
  silence_threshold: 0
  silence_size : 0
  boundary     : 6206523236469964800
  appl_ptr     : 0
  hw_ptr       : 0

The Serial_Init function documentation is confusing

The documentation states:

BaudRate Serial baud rate, in bits per second.
DoubleSpeed Enables double speed mode when set, halving the sample time to double the baud rate.

One might think that setting BaudRate to X and DoubleSpeed to true should result in an actual baud rate of 2*X.

In fact the BaudRate argument has to be the actual baud rate.

CDC BootLoader not Leonardo Compatible

I tried to compile the latest CDC BootLoader for my Pro Micro(well not a leo but a 32u4) and it turn out that i cannot reupload sketches to the board. The Arduino software tries to touch the Serial at 1200 and tries to reupload the Code. But its not working:

Connecting to programmer: .avrdude: Send: . [1b] 
avrdude: Send: S [53] 
avrdude: ser_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

With the older Pro Micro source (recompiled with the older Lufa) its working fine.
I am trying to figure out why this happens.

I also have a similar problem with my HoodLoader2 project. After a serial touch the leds start flickering, usb is detached but no sketch and no bootloader starts. Just the leds are flickering. I am wondering if i set the Watchdog timer wrong in my source.

Any Idea?

LUFA USB module in Atmel Studio 7 appears to be out of date

I noticed this while moving a program written elsewhere over to Atmel Studio. When I tried to use the ASF version of LUFA, there was a mismatch in the definition of CALLBACK_USB_GetDescriptor between my descriptors.c and the version of device.h brought into the project by ASF.

The relevant change is commit 92e9cb7. In the version of LUFA downloaded from fourwalledcubicle wIndex is a uint16, whereas the version in AS is a uint8 - as it was before the commit.

This seems to appear both when adding the LUFA USB module through ASF wizard, and when opening the CLASS CDC demo project included in the LUFA extension. The easiest way to reproduce it is to open the CDC demo and look at the definition in descriptors.h and devices.h

I have not looked to see if anything else is out of date.

Forking to customize for a specific board?

Hello,

I've forked LUFA in order to modify it to work specifically with the Arduino UNO R3 (e.g. make the Board folder and the files within, modify the makefiles, etc). My intention is to keep the master branch of my fork identical to the master branch here, then do my modifications on a separate branch called arduino-uno-r3. Whenever the repo here gets updated, I'd pull into master, then merge those changes into arduino-uno-r3 and update as necessary.

How would you recommend to handle this situation? Is my fork a suitable way to develop for a specific board? Or is there some other way you'd recommend?

LUFA-111009 download from github seems wrong

I get significantly different versions of LUFA-111009 depending on where I download it from.

If I download LUFA-111009.zip from googlecode.com, it has a sha1sum of fe6abf1cef6fb924d58f9158c5297e305b169a8f and it defines ENDPOINT_DIR_IN to be 0x80 in USBController.h:

/** Endpoint address direction mask for an IN direction (Device to Host) endpoint. This may be ORed with
 *  the index of the address within a device to obtain the full endpoint address.
 */
#define ENDPOINT_DIR_IN                    0x80
//@}

If I go to LUFA on fourwalledcubicle.com, the link for LUFA-111009 points to http://www.github.com/abcminiuser/lufa/archive/LUFA-111009.zip, which means I get the files in the commit tagged with LUFA-111009. Currently the LUFA-111009 tag points at commit b838991, which defines ENDPOINT_DIR_IN to be 0x01 in Endpoint_AVR8.h:

/** Endpoint data direction mask for \ref Endpoint_ConfigureEndpoint(). This indicates that the endpoint
 *  should be initialized in the IN direction - i.e. data flows from device to host.
 */
#define ENDPOINT_DIR_IN                         (1 << EPDIR)
//@}

I think the git tag for LUFA-111009 was placed on the wrong commit. Perhaps it should be moved from b838991 to either c5a05ed or beb069b, since both of those claim to be the "Commit for the 111009 release.".

Regardless of where the git tag points to, I would suggest that the link on fourwalledcubicle.com should point to the original LUFA-111009.zip (which has a sha1sum of fe6abf1cef6fb924d58f9158c5297e305b169a8f). The reason is that the top-level folder in your original ZIP file is named "LUFA-111009" but the ZIP file created by github uses "lufa-LUFA-111009" instead. This difference makes it hard for people to communicate about LUFA-111009 and write correct instructions for how to extract it and use it. Old instructions that were based on the original ZIP file will generally not work.

Documentation Error: RAISE_EVENT macro does not exist

The description of the NO_LIMITED_CONTROLLER_CONNECT token states that on controllers with limited VBUS sensing capabilities, VBUS should be sensed by the application and the events raised by using the RAISE_EVENT macro. However, there is no RAISE_EVENT macro anywhere in the source code.

The documentation is also unclear about what should be done with the USB_DeviceState variable. Assuming I can figure out what state should be set when VBUS goes up (the documentation does not give a hint), it is still unclear how I get LUFA to do whatever is needed so that enumeration can start. Maybe this can work if the application calls USB_USBTask() regularly, but when INTERRUPT_CONTROL_ENDPOINT is set, then some interrupt must happen before any LUFA code can react to the change in USB_DeviceState. This looks like a documentation gap to me.

HID Bootloader does not work

I tried the c program which seems to work now. However I got serious bootloader problems now:

The sketch will not load. It seems to be a magic key problem but I noticed several weird errors. It must be something simple i guess? I even tried a fixed bootkey address which the arduino team uses:

//uint16_t MagicBootKey ATTR_NO_INIT;

volatile uint8_t *const MagicBootKeyPtr = (volatile uint8_t *)0x8000;
#define MagicBootKey *MagicBootKeyPtr

/** Special startup routine to check if the bootloader was started via a watchdog reset, and if the magic application
 *  start key has been loaded into \ref MagicBootKey. If the bootloader started via the watchdog and the key is valid,
 *  this will force the user application to start via a software jump.
 */
void Application_Jump_Check(void)
{
    LEDs_Init();

    LEDs_SetAllLEDs(0);

    if(MCUSR & (1 << WDRF))
    LEDs_TurnOnLEDs(LEDS_LED1); //rx

    if(MagicBootKey == MAGIC_BOOT_KEY)
    LEDs_TurnOnLEDs(LEDS_LED2); //tx

    /* If the reset source was the bootloader and the key is correct, clear it and jump to the application */
    if ((MCUSR & (1 << WDRF)) && (MagicBootKey == MAGIC_BOOT_KEY))
    {
        MagicBootKey = 0;

        // cppcheck-suppress constStatement
        ((void (*)(void))0x0000)();
    }
}

But only the first led goes on.

MCU          = atmega32u4
ARCH         = AVR8
BOARD        = LEONARDO
F_CPU        = 16000000
F_USB        = $(F_CPU)
OPTIMIZATION = s
TARGET       = BootloaderHID
SRC          = $(TARGET).c Descriptors.c $(LUFA_SRC_USB)
LUFA_PATH    = ../../LUFA
CC_FLAGS     = -DUSE_LUFA_CONFIG_HEADER -IConfig/
LD_FLAGS     = -Wl,--section-start=.text=$(BOOT_START_OFFSET)

# Flash size and bootloader section sizes of the target, in KB. These must
# match the target's total FLASH size and the bootloader size set in the
# device's fuses.
FLASH_SIZE_KB        := 32
BOOT_SECTION_SIZE_KB := 4

[...]

avrdude:
    avrdude -patmega32u4 -cstk500v1 -P/dev/ttyACM0 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xCB:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m
    avrdude -patmega32u4 -cstk500v1 -P/dev/ttyACM0 -b19200 -Uflash:w:./$(TARGET).hex:i -Ulock:w:0x2F:m

Edit: The leds were off because of my wrong bootkey address "fix". The problem was something different, see PR #77

Duplicate ISR() under some condition

For following code:

• lufa/LUFA/Drivers/USB/Core/AVR8/USBInterrupt_AVR8.c
• lufa/LUFA/Drivers/USB/Core/UC3/USBInterrupt_UC3.c

I see duplicate definition of ISR(...). Let me focus on AVR side for simplicity.

For ISR definition on line 77, it is always there.
For ISR definition on line 261, it is conditional with:

#if defined(INTERRUPT_CONTROL_ENDPOINT) && defined(USB_CAN_BE_DEVICE)

Do you expect to duplicate definition if INTERRUPT_CONTROL_ENDPOINT and USB_CAN_BE_DEVICE are defined?

Is this some fancy function overloading? But this is C code ...

make doxygen fails with problem in KnowIssues.txt

make doxygen complains of an unknown command in KnownIssues.txt \cB on line 43. I think it should be "\c BOARD" rathern than "\cB OARD" but I am not familiar with doxygen.

Fixing this moves things along, but then is complains:-

/home/david/git/lufa/Demos/Device/ClassDriver/DualMIDI/Descriptors.h:56: warning: unable to resolve reference to `USB_MIDI_Descriptor_Jack_Endpoint_t' for \ref command
../../../../LUFA/Build/lufa_doxygen.mk:86: recipe for target 'doxygen' failed

and I am unsure how to fix this.

Thanks

David

CDC Bootloader does not work with AVR-GCC 4.9.2

I tried to compile with the newest winavr patch with avr-gcc 4.9.2 from here and this totally breaks the bootloader:
http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/

It compiles with 200 bytes less kb but wont work at all. Just want to note it here, if anyone else rans into the problem. 4.9.2 is really the most up to date compiler, not even sure if its declared stable.

4.8.1 worked for me. (under linux)

But it could be that my winavr installation is broken.
edit: it really seems that the patch isnt working as it is supposed to do.

Issues with static libraries

Hello,

I'm trying to add LUFA to a firmware that is built using several modules, each built in a separate static library, and linked together to produce the final elf file, but I encounter a link error with CALLBACK_USB_GetDescriptor.
In order to keep it simple, I tried to replicate the project's structure using the ClassDriver MIDI Device demo in your repository, using my build system (based on CMake).

The whole project looks like this:

• LUFA, where only the sources from LUFA/Drivers/USB are compiled.
• lufa-demo-core, which contains the Descriptors and MIDI files from the demo, with the following modifications:
  • The main function has been removed from MIDI.c, and its contents have been spread out to two functions, init and process (one to be called before the loop, and the other one within).
  • The appropriate declarations for init and process have been added in MIDI.h
• lufa-demo-firmware, which contains a single main.c file, implementing the main function calling init and process as described.

LUFA and lufa-demo-core each compile to liblufa.a and liblufa-demo-core.a, C static libraries.

lufa-demo-firmware links against these static libs to produce the final elf, but fails to find the CALLBACK_USB_GetDescriptor symbol, implemented in Descriptors.c, from its usage in USB_Device_ProcessControlRequest in the file DeviceStandardReq.c.

All LUFA components use the same LUFAConfig.h file (the one from the demo), and the signature for CALLBACK_USB_GetDescriptor matches in both the implementation and the call (so it's not a signature issue).

Please note that when building the demo files as-is in a single executable target, the link step succeeds.

I can't attach archives on GitHub, so here's a link to the modified demo files:
https://drive.google.com/file/d/0B7AbgN8zxRh0SmE0UDBoV0dWQTA/view?usp=sharing

More details if it helps:

• Building with avr-gcc 4.8.3 on Mac OS X 10.9.5, avr-libc version 1.8.1
• Building for ATmega32U4 (Arduino Leonardo), 16MHz for both F_CPU & F_USB.

Any insight would be most welcome !

Best regards,
Francois.

New release

Its been a year since the last release, I suggest to create a new one.
There were a few bootloader fixes from my side which are very important. There are some opened issue left about that though. Not sure how long you want to wait for a new release, this should just be a reminder, that a year passed now since the last release.

XMega Bootloader Support

Hey,

I'm wondering what is going on with XMega support with this library. XMega's are better than the regular AVR8s in many ways in my opinion and they aren't exactly new anymore.

I noticed there is a pull request from 2013 for some XMega Bootloader support, but not merged here yet. Any plans of doing that?

Anyway, I would be glad to hear your thoughts on XMega series support with this library and I hope there will be some. Especially the Bootloaders.

Thanks!

Wrong type for the wIndex parameter of the CALLBACK_USB_GetDescriptor function

It should be uint16_t, not uint8_t.

Support for large TWI reads

Currently, TWI_ReadPacket and TWI_WritePacket use a uint8_t for the data packet length. However, many EEPROMs allow reading sequential addresses over more than a 256 address range. I would suggest changing:
uint8_t Length
to:
uint16_t Length

AVRISP-MKII Clone fails to program XMEGA EEPROM

Bug report from a user.

An XMEGA128A1 fails to program EEPROM using Atmel Studio 6.1.2730 unless the chip is erased first. This points to the EEPROM not being erased correctly on some XMEGA parts (targeted memory erase procedure).

Quote from the user:

This procedure works for me (PROGRAM FLASH or PRODUCTION FILE PROGRAM)
At first i must do: Memories->Device=Erase chip,
even always ERASE MEMORY BEFORE PROGRAMMING is checked.
After then i can programming ic (if i use PRODUCTION FILE PROGRAM mode)
(must uncheck EEPROM), if i don`t do that i always receive error:
Verifying EEPROM...Failed! address=0x0000 expected=0x41 actual=0x00...

Version.h not used?

https://github.com/abcminiuser/lufa/blob/master/LUFA/Version.h

Is this used somehere? I cannot find a real use case, also the variables are zero and dont contain a version. Setting a version could be useful for further projects that rely on a specific lufa version.

make avrdude does not work with flip!

avrdude does not allow programming of "flash" via flip. I had to modify LUFA/Build/lufa_avrdude.mk to allow me to select the "application" memory. I suggest either adding a variable as I did, or adding a separate target, ie: avrdude-application.

...
# Default values of optionally user-supplied variables
AVRDUDE_PROGRAMMER ?= jtagicemkii
AVRDUDE_PORT       ?= usb
AVRDUDE_FLAGS      ?=
AVRDUDE_MEMORY     ?= flash
...
# Programs in the target FLASH memory using AVRDUDE
avrdude: $(TARGET).hex $(MAKEFILE_LIST)
    @echo $(MSG_AVRDUDE_CMD) Programming device \"$(MCU)\" FLASH using \"$(AVRDUDE_PROGRAMMER)\" on port \"$(AVRDUDE_PORT)\"
    avrdude $(BASE_AVRDUDE_FLAGS) -U $(AVRDUDE_MEMORY):w:$< $(AVRDUDE_FLAGS)
...

USB_Device_GetSerialString Serial Number Nibble Question

Hi,

Was wondering if anyone know if the bytes for UNIQUE SERIAL NUMBER for some devices (eg ATMEGA16U2) mentioned in the datasheet,

Unique Serial Number From 0x000E to 0x0018

are displayed in ,

High Nibble First
0x1A, display as 1A

or

Low Nibble First
0x1A, display as A1

From LUFA's Device_AVR8.h,

uint8_t SerialByte = boot_signature_byte_get(SigReadAddress);
if (SerialCharNum & 0x01)
{
    SerialByte >>= 4;
    SigReadAddress++;
}
SerialByte &= 0x0F;

Seems like the LOW nibble were displayed first.

When checking the UNIQUE SERIAL NUMBER using AVR STUDIO, the bytes were displayed HIGH nibble first.

Serial Number Read from AVR Studio

Serial Number returned by Arduino Serial Port that is using LUFA's code

From AVR Studio
Serial Number = 5732373336361511181F
From LUFA
Serial Number = 752373336363511181F1

I can't seems to find documents from ATMEL about this. If anyone know how this works, please share some light.

Cheers
JP

XMEGA TWI_XMEGA.c - error: 'twi' undeclared (first use in this function)

In lufa-LUFA-140302/LUFA/Drivers/Peripheral/XMEGA/TWI_XMEGA.c it looks like the capitalization of twi (in the function body) vs TWI (arguments) is mismatched.

Causes compilation errors like "XMEGA TWI_XMEGA.c - error: 'twi' undeclared (first use in this function)".

The code compiles once the capitalization is normalized.

Investigate switch to DMBS

Since I've forked out a modified version of the LUFA build system as DMBS, it would be better maintenance-wise if I can integrate DMBS with some extra modifications in LUFA rather than having duplicated code.

[HID] No error on too big bootloader size

If i try to compile the CDC bootloader with 2kb setting (for 32u4) I get a compile error.
For the HID I dont get a compile error.

It would be nice to a) get an error and b) maybe improve the error, so one know whats going on.

HID_REPORT_REQUEST_Feature definitions missing

Currently there is only HID_REPORT_ITEM_Feature which is used to generate the RAWHID report descriptor. However with HID you can also differentiate between In, Out, Feature inside the Get/Set_Report Request. Those values differ from the definition above (+1). Something like HID_REPORT_TYPE_Feature is wished.

Currently available:
http://www.fourwalledcubicle.com/files/LUFA/Doc/151115/html/group___group___u_s_b_class_h_i_d_common.html#gga3c0de6e2f6380c88937a5f09bcbf022ea468b3fdb884153aaefb634c9823f64bb

Requested:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/libraries/HID/src/HID.h#L57

Source in the USB Spec:
HID Request Type HID1.11 Page 51 7.2.1 Get_Report Request

Please add those 3 values, as it is really helpful.

Demo and application INF files need to be signed

With Windows's gestapo driver signing now being truly enforced, we need signed versions of the LUFA demo INF driver files to be able to continue to use them on Windows machines. Apparently CDC-ACM now works on Windows 10 without any driver files (yay!) but Windows 8 and below still have a lot of market share, and RNDIS and other projects still require a signed driver even on Win10.

The list of driver INF files requiring signing are:

• ./Bootloaders/CDC/LUFA CDC Bootloader.inf
• ./Demos/Device/ClassDriver/DualVirtualSerial/LUFA DualVirtualSerial.inf
• ./Demos/Device/ClassDriver/RNDISEthernet/LUFA RNDIS.inf
• ./Demos/Device/ClassDriver/VirtualSerial/LUFA VirtualSerial.inf
• ./Demos/Device/ClassDriver/VirtualSerialMassStorage/LUFA VirtualSerialMassStorage.inf
• ./Demos/Device/ClassDriver/VirtualSerialMouse/LUFA VirtualSerialMouse.inf
• ./Demos/Device/LowLevel/BulkVendor/WindowsDriver/LUFA_Bulk_Vendor_Demo.inf
• ./Demos/Device/LowLevel/DualVirtualSerial/LUFA DualVirtualSerial.inf
• ./Demos/Device/LowLevel/RNDISEthernet/LUFA RNDIS.inf
• ./Demos/Device/LowLevel/VirtualSerial/LUFA VirtualSerial.inf
• ./Projects/Benito/LUFA Benito Programmer.inf
• ./Projects/LEDNotifier/LUFA LED Notifier.inf
• ./Projects/SerialToLCD/LUFA SerialToLCD.inf
• ./Projects/USBtoSerial/LUFA USBtoSerial.inf
• ./Projects/Webserver/LUFA Webserver RNDIS.inf
• ./Projects/XPLAINBridge/LUFA XPLAIN Bridge.inf

The vast majority of these are effectively identical, except for different VID/PID and descriptions. This means signing should be relatively easy once we get the base classes (CDC, RNDIS) figured out.

@ehajo @mitchjs will you be able to assist? Does someone else with a valid signing certificate wish to help out?

Compile option for far-flash pointer descriptors

User request:

New config directive USE_FLASH_FAR_DESCRIPTORS to enable FLASH descriptors anywhere, i.e. read memory pgm_*_far fuctions. It's not needed for main program but for large chip bootloaders when RAMPZ register is needed to access bootloader's FLASH. Currently USE_RAM_DESCRIPTORS must be used which allocates sligtly more RAM for consts. It's rather minor problem but I got it when developing bootloader for AT90USB1286.

AVRISP-MKII Clone non-functional under Atmel Studio 7

There's been a payload minor revision change, but that alone doesn't fix the broken communication. I suspect there has been an extension to the protocol that I need to add to the existing clone firmware to make it compatible with AS7.

LUFA build system extendability

Trying to develop my own library for CAN controllers and write/adapt CANopen stack, all using LUFA build system (and unfortunatelly also strongly coupled to it) I found that the first asignment of BASE_CC_FLAGS varible in lufa_build.mk prevents me from seamlessly adding (concatenating) more compiler options, like -I or -D necessary in my own library without changing the LUFA makefiles. I add my own source files and specific variables in a [libname]_sources.mk makefile which looks similarly to lufa_sources.mk.

The easy workaround is to change the operator in the first asignment to the BASE_CC_FLAGS variable from := to +=
The more proper way imho would be to decouple lufa_build.mk from LUFA library, that is to move F_USB and LUFA_PATH variables out of lufa_build.mk into lufa_sources.mk. As a result we would get a general extendable biuld system initially configured to compile with LUFA library.

Regards! And thanks for the great library.

multiple definition of `__vector_17'

Hey guys
I try to compile the examples and get this weird error.

/home/robert/src/lufa/Projects/AVRISP-MKII/Lib/ISP/ISPTarget.c:119: multiple definition of __vector_17'
obj/SoftUART.o:/home/robert/src/lufa/Projects/XPLAINBridge/Lib/SoftUART.c:102: first defined here
/usr/lib/gcc/avr/4.8.1/../../../avr/bin/ld: Disabling relaxation: it will not work with multiple definitions
collect2: error: ld returned 1 exit status
../../LUFA/Build/DMBS/DMBS/gcc.mk:241: recipe for target 'XPLAINBridge.elf' failed
make[2]: *** [XPLAINBridge.elf] Error 1
make[2]: Leaving directory '/home/robert/src/lufa/Projects/XPLAINBridge'
makefile:44: recipe for target 'XPLAINBridge/' failed
make[1]: *** [XPLAINBridge/] Error 2
make[1]: Leaving directory '/home/robert/src/lufa/Projects'
makefile:19: recipe for target 'all' failed
make: *** [all] Error 2`

Any ideas?

HID Bootloader Python Host APP errors.

1. You should add #!/usr/bin/python as first line of the python file.
2. The intelhex link is down. http://bialix.com/intelhex/ I used this instead: https://pypi.python.org/pypi/IntelHex
3. pywinusb is not linux compatible. I cannot run to python script :/

OSX 10.11 Unable to open device

OSX 10.11, built against 10.11 SDK, it states "unable to open device" Not really sure how to proceed.

USB init process violates datasheet recommendations

As found by @NicoHood, the current core init code violates the best practice instructions in the datasheet for the U2 series (at a minimum). The PLL and pad regulators should be initialized before enabling the USB core.

Documentation cannot be generated

I get the following error when I try to follow the instructions for using Doxygen to generate the documentation.

Executing "make doxygen" on all LUFA library elements.

/Library/Developer/CommandLineTools/usr/bin/make -C LUFA doxygen
grep: /Version.h: No such file or directory
 [DOXYGEN] : Configuration file "doxyfile" with parameters "QUIET=YES PROJECT_NUMBER="
if ( ( cat doxyfile ; echo "QUIET=YES" ; echo "PROJECT_NUMBER=" ) | doxygen - 2>&1 | grep -v "warning: ignoring unsupported tag" ;); then exit 1; fi;
warning: Tag `CLANG_ASSISTED_PARSING' at line 1010 of file `-' belongs to an option that was not enabled at compile time.
         To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u", or recompile doxygen with this feature enabled.
warning: Tag `CLANG_OPTIONS' at line 1018 of file `-' belongs to an option that was not enabled at compile time.
         To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u", or recompile doxygen with this feature enabled.
make[1]: *** [doxygen] Error 1
make: *** [doxygen] Error 2

Are you planning support for the Teensy 3.X?

before I go ahead and start working on it, do you already have planned support for it? Can you think of any reason why it wouldn't work?

Thanks

USB device hangs waiting for an OUT packet

Hi Dean,

I'm writing a firmware that emulates a dualshock 4 controller. The goal of this firmware is only to pair a specific bluetooth address with a PS4 (Sony blocked USB inputs...).
The source code is available at https://github.com/matlo/GIMX-firmwares/tree/master/EMUPS4

The issue I'm running into is that there is a problem during the enumeration that only occurs with the PS4 (it works fine with my PC). The USB device hangs waiting for an OUT packet after sending the response to the second get device descriptor request. The loop is at line 74 of the Template_Endpoint_Control_W.c file.
https://github.com/abcminiuser/lufa/blob/master/LUFA/Drivers/USB/Core/AVR8/Template/Template_Endpoint_Control_W.c#L74

Adding the following code before the closing brace seems to work-around the issue:

    else if (Endpoint_IsSETUPReceived())
      return ENDPOINT_RWCSTREAM_HostAborted;

Does this seem a valid fix to you?

Regards

Typos in USB_Device_SetConfiguration

lufa/LUFA/Drivers/USB/Core/DeviceStandardReq.c

Line 155 in 1d2680b

#elif defined(USE_SRAM_DESCRIPTORS)

I think there are two typos:

• USE_SRAM_DESCRIPTORS should be USE_RAM_DESCRIPTORS
• MEMSPACE_SRAM should be MEMSPACE_RAM

dfu-programmer eeprom command

The command for programming EEPROM memory with dfu-programmer has changed in newer versions.

The one I have 0.6.2, uses 'flash-eeprom' instead of 'eeprom-flash'.

This still works in the latest version, but the recommended way appears to be 'flash --eeprom'

Also an erase command is needed before programming EEPROM (at least on atmega devices), which will leave the program memory blank.

hid_bootloader_cli is based on rather older teensy_loader_cli

It seems teensy_loader_cli which your hid_bootloader_cli is forked from has been updated to accommodate newer arms with larger buffer allocation etc.

I updated newer teensy_loader_cli to accept LUFA firmware. (Unlike your current approach to try for both, I made USB ID choice to be deterministic. If compiled code is called as hid_bootloader_cli, it only works with LUFA firmware.

See it in the branched teensy_loader_cli repo

• https://github.com/osamuaoki/teensy_loader_cli
  I tried to merge as much fixes as you did into htis too.

Also code itself is

• https://github.com/osamuaoki/teensy_loader_cli/blob/master/teensy_loader_cli.c

I hope this patch set is more easy to track teensy code in future.

Osamu

CDC Bootloader has no PROGMEM Device descriptor

https://github.com/abcminiuser/lufa/blob/master/Projects/USBtoSerial/Descriptors.c#L46
vs
https://github.com/abcminiuser/lufa/blob/master/Bootloaders/CDC/Descriptors.c

Currently searching what has to be changed in order to fix this. But it seems just the PROGMEM is missing.
Or is there any reason for this???

Edit:
Those variables also sit in RAM:

00800208 D ProductString
0080022a D ManufacturerString
0080023e D LanguageString

Adding PROGMEM saves ~150 bytes of ram.

NicoHood/HoodLoader2@fc2d90a
The weird thing is, that my program stops working after adding the PROGMEM

This is related to that. However I do need those bytes for my bootloader. Why does a bootloader not support PROGMEM and a normal program does?
http://www.avrfreaks.net/forum/lufa-hid-bootloader-name
http://www.avrfreaks.net/forum/using-dynamic-serial-string-lufa-usb-descriptor

LUFA fails to wake up host

The following code seems to have no effect when run on an ATmega32U4 whose host is a Mac running Sierra.

if (USB_DeviceState == DEVICE_STATE_Suspended)
    if (USB_Device_RemoteWakeupEnabled)
        USB_Device_SendRemoteWakeup();

Critical CDC Bootloader USB HUB bug

This issue has nothing to do with issue #42.

The story:
I am developing a 16u2 CDC Bootloader variation and I got a very weird error. I tried with my arduino leonardo now. There is no such an error (with the official bootloader). Then I recompiled the CDC Bootloader from lufa and the bug appeared.

The bug:
Use a USB3 port on your pc (tried with two pcs) and connect a usb 2.0 hub to it(usb 3 wont cause the bug). plug in the arduino with the cdc bootloader and try to upload a sketch via the ide. The verification will fail. Now do the same and connect a second device to the usb port like a mouse. For some reason the uploading now doesnt fail.

The sketch will upload anyways but the verification wont fail. I tried with 2 different pcs and different os. (win7, win8, ubuntu). I tried 4 different usb 2 hubs (usb 3 works). I did not try usb 2 pc host ports because i only have usb3 ports. I tried different drivers for windows (shouldnt matter cause linux has this bug too).

There are also different errors like a "dead" usb port until you plug in/out another device on the hub. As long as you dont do this, the cdc bootloader usb port will be dead, you can replug it as long as you want.

It seems that the old CDC bootloader from the Arduino team (with older lufa) has not this problem. I am now searching for the error. If it is the lufa version or the code of the bootloader.

Fuses used (tested with 16u2, 32u2 and 32u4):

#fuses (HoodLoader2 only, not suitable for DFU)
HoodLoader2atmega16u2.bootloader.low_fuses=0xFF
HoodLoader2atmega16u2.bootloader.high_fuses=0xD8
HoodLoader2atmega16u2.bootloader.extended_fuses=0xCB (0xFC for 32u4)
HoodLoader2atmega16u2.bootloader.unlock_bits=0x3F
HoodLoader2atmega16u2.bootloader.lock_bits=0x2F

To recreate this you only need an Arduino Uno/Mega (16u2) board or a leonardo/(pro)micro(32u4) board and test one of the versions. To upload sketches to the 16u2 you need my hid project and hoodloader2 project on github. It'd be easier to test the 32u4 though.

edit: @dean: any idea where the bug could be located, where i have to start searching?

Request for MSC-CDC Composite Bootloader for ATmega32u4

Is it possible to make a MSC-CDC Composite Bootloader for ATmega32u4 that can switch in between MSC and CDC mode on certain event (like rapidly pressing reset button twice)

@watterott have a similar implementation based on ATSAMD21

Wrong at90usb82 Signatures

https://github.com/abcminiuser/lufa/blob/master/Bootloaders/DFU/Descriptors.h#L121
https://github.com/abcminiuser/lufa/blob/master/Bootloaders/CDC/Descriptors.h#L87

Might also be in different bootloaders.
Should be 0x93 instead of 0x94 (8kb flash, not 16).

Page 246 http://www.atmel.com/images/doc7707.pdf

Issue found here:
NicoHood/HoodLoader2#6 (comment)

avrdude.exe: Device signature = 0x1e9482
avrdude.exe: Expected signature for AT90USB82 is 1E 93 82

Also have a look at the issue filed for my HoodLoader2 (which I linked above):
CDC programming does not work for an 8u2 but with an at90usb82 (with the signature patched).
The 8u2 setting only works if you use avrdude with at90usb82 settings and the -F switch. So I think it is an avrdude issue, not lufa. Any ideas about that?

Edit: avrdude bug: arduino/Arduino#3645

Is there a way to make a USB device running LUFA to disconnect from then reconnect to its host while remaining powered on the entire time?

AVR32 host mode failure

Report from user, AVR32 host mode fails to enumerate. Re-test of latest code on the EVK1101 required to confirm.

BootloaderDFU.c replies with wrong signature

Hi,

there are four bytes which should be output as signature:

30h Read Manufacturer Code
31h Read Family Code
60h Read Product Name
61h Read Product Revision

in BootloaderDFU.c I see (in todays Git-download):

    const uint8_t SignatureInfo[4]  = {0x58, AVR_SIGNATURE_1, AVR_SIGNATURE_2, AVR_SIGNATURE_3};
    ...
          ResponseByte = SignatureInfo[DataIndexToRead - 0x60 + 3];

Questions:

a) Isn't the manufacture always 0x1E for Atmel, i.e. the AVR_SIGNATURE_1 value? What I see missing is the Product Revision where we might need an arbitrary value, but at the end of the list?

b) To cover access to the values which should be replied for the offset 0x60 and 0x61: maybe + 3 should read + 2 only. 0x61 would otherwise point behind the array when we add 3.

-- Reuti.