[DO NOT MERGE] Fix bootloader and USB improvements on 32u4 #4793
Conversation
|
You may want to update comment as well to |
| #endif | ||
| // Clean up RAMEND key | ||
| *(uint16_t *)magic_key_pos = 0x0000; | ||
| } |
There was a problem hiding this comment.
Here is an error. You need to add an #if around the bracket too.
facchinm
force-pushed
the
avr_usb_bootloader
branch
from
cc773bf to
cc1e835
Compare
|
@NicoHood , I fixed the bug you spotted and squashed it, thanks for taking a look! |
|
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4793-BUILD-539-linux32.tar.xz ℹ️ The |
|
Great! It compiles now fine. It adds some overhead to the older bootloader boards, but removes it for newer boards. |
|
@facchinm @NicoHood You may want to update How about also? |
facchinm
changed the title
|
@beaufortfrancois |
Replaces arduino#4280, only checks for the bootloader once Tested with Hoodloader2, should work with every LUFA-derived bootloader released after 2014 (.apitable_signatures section must be placed at end of the flash) BootloaderAPITable.S : .global BootloaderAPI_Signatures BootloaderAPI_Signatures: .long BOOT_START_ADDR ; Start address of the bootloader .word 0xDF00 ; Signature for the CDC class bootloader .word 0xDCFB ; Signature for a LUFA class bootloader makefile: BOOT_API_LD_FLAGS += $(call BOOT_SECTION_LD_FLAG, .apitable_signatures, BootloaderAPI_Signatures, 8)
facchinm
force-pushed
the
avr_usb_bootloader
branch
from
cc1e835 to
e6026dc
Compare
|
✅ Build completed. Please test this code using one of the following: ⬇️ http://downloads.arduino.cc/javaide/pull_requests/arduino-PR-4793-BUILD-549-linux32.tar.xz ℹ️ The |
|
@reillyeon Does that make sense? |
|
I thought those fixes were applied already? @facchinm I made the official lufa bootloader Arduino compatible with a few changes. I think this is a better idea than modifying HoodLoader2, as I've changes a lot to non standard to get the maximum size reduction. lufa has also additional fetures as eeprom, lock bit etc support (as it has more room without the serial bridge). The leds blink a bit different, but to be honest this is totally fine to me, as it will use the usb tx/rx leds which I think is quite a good idea anyways. I have not added the old magic key support, as people who use the new bootloader will use the new ide. I wanted to keep lufa at least simple, feel free to add this little patch yourself. Link: abcminiuser/lufa#86 |
|
@NicoHood , the latest patch (runtime discovery of bootloader version) was cherrypicked, 197fe07 instead brings some headache on win10 (if we are declaring as USB 2.1 we must provide a BOS descriptor, otherwise the drivers won't load at all). I still had no time to tackle this and find a good workaround. |
|
BTW, the LUFA patches are very clever and we could really think about integrating them to be as mainline as possible 👍 |
|
Couldn't we just fix this on Windows 10 by responding with a basic BOS descriptor with a container ID? |
|
The ram/flash usage overhead was quite high when I coded a basic BOS response, and in a resource constrained device like 32u4 it's a huge problem losing 500bytes for a WIN10 specific issue. |
|
I'll see what I can do to shrink it. That seems like a lot of bytes. |
|
If "runtime discovery of bootloader version" was cherry picked, why is the commit still shown in this PR? It would be nice if you could also test my Lufa patch and add a comment if it works. I really would like to see this as new bootloader, as this would be the simplest and clearest option with the most features (and further bugfixes from lufa) we can get. |
Various fixes for USB-enabled AVR devices (32u4).
Commit 197fe07 needs some community testing (to make sure that "advertising" as USB2.1 has no side affect on any platform)