Atmega32u4 mass storage bootloader compilation, broken in AVR-GCC 4.9.2?

324 views
Skip to first unread message

sv1...@gmail.com

unread,
Sep 26, 2016, 5:20:55 AM9/26/16
to LUFA Library Support List
Hi,

Got my atmega32u4 projects done with LUFA just fine and now would like to see a way of making them field upgradeable via the mass storage bootloader.

Yet, when I try to compile the bootloader got errors.

Using the AVR-GCC 4.9.2

C:\Atmel\Projects\lufa-master\Bootloaders\MassStorage>avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.5.3_1700) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.



Makefile is

*************************************
MCU          = atmega32u4
ARCH         = AVR8
BOARD        = MICRO
F_CPU        = 16000000
F_USB        = $(F_CPU)
OPTIMIZATION = s
TARGET       = BootloaderMassStorage
SRC          = $(TARGET).c Descriptors.c BootloaderAPI.c BootloaderAPITable.S Lib/SCSI.c Lib/VirtualFAT.c $(LUFA_SRC_USB) $(LUFA_SRC_USBCLASS)
LUFA_PATH    = ../../LUFA
CC_FLAGS     = -DUSE_LUFA_CONFIG_HEADER -IConfig/ -DBOOT_START_ADDR=$(BOOT_START_OFFSET)
LD_FLAGS     = -Wl,--section-start=.text=$(BOOT_START_OFFSET) $(BOOT_API_LD_FLAGS)

# 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
******************************************


And the error I got is

******************************************
c:/program files (x86)/atmel/studio/7.0/toolchain/avr8/avr8-gnu-toolchain/bin/..
/lib/gcc/avr/4.9.2/../../../../avr/bin/ld.exe: section .apitable_trampolines loa
ded at [00007fa0,00007fb7] overlaps section .data loaded at [00007e38,00007fb7]
collect2.exe: error: ld returned 1 exit status
../../LUFA/Build/DMBS/DMBS/gcc.mk:238: recipe for target 'BootloaderMassStorage.
elf' failed
make: *** [BootloaderMassStorage.elf] Error 1

******************************************


Any hints on how to successfully recompile LUFA mass storage bootloader for atmega32u4 ?


Christos

USB Typewriter

unread,
Sep 27, 2016, 12:41:32 AM9/27/16
to LUFA Library Support List
I am very interested in your bootloader project.  I hope to do the same sort of thing with my USB Typewriter project, also using the 32u4.  Please keep us posted what you turn up.

-Jack

sv1...@gmail.com

unread,
Sep 27, 2016, 6:47:29 AM9/27/16
to LUFA Library Support List
To add in my initial post, I do have tested most of the bootloaders, in short, CDC and DFU work just fine for my projects,
Printer build ok and enumerated properly on a PC system but loaded applications do not work.

I prefer though the Mass Storage Bootloader thus I'm trying to make it work.

Mass storage, tested with BOARD MICRO generate the error mentioned. I attach the complete build log file BootloaderMassStorageBuild_BOARD_MICRO_failed.txt.
Mass storage, tested with BOARD NONE does compile ok. Yet loaded applications do not work. After burning the bootloader I plugged it on PC USB port, PC displayed the LUFA BOOT drive and I drag-drop there the file FLASH.BIN (which is a copy of the BulkVendor.bin). Ejected the drive properly from OS. But then, the BulkVendor example did not fire up, it did not enumerated at all like nothing has plugged in. The BulkVendor though on itself alone without bootloader does enumerate ok, and it also works ok with CDC and DFU bootloaders.
I attach the complete build log file BootloaderMassStorageBuild_BOARD_NONE.txt.

I also attach the build log BulkVendorBuild.txt from the example that I used to test the proper bootloader application loading.

Now, I would really appreciate if someone tell me what am I doing wrong here..


Christos
BootloaderMassStorageBuild_BOARD_NONE.txt
BootloaderMassStorageBuild_BOARD_MICRO_failed.txt
BulkVendorBuild.txt

Dean Camera

unread,
Sep 30, 2016, 11:23:03 PM9/30/16
to lufa-s...@googlegroups.com

Hi Christos,

That section overlap error indicates that the bootloader is too large to fit into your target device. I just tried it and got the same result - it's the MICRO board's LED driver that pushes it slightly over the edge.

The mass storage bootloader is actually closer to 6KB, with the additional 2KB of space on the smaller devices coming from an "AUX" flash section I define just before the real bootloader section on devices with the smaller bootloader area. Functions in the bootloader code are then relocated into that AUX section (except for the flash functions, which are required to be in the bootloader section to work correctly) via the AUX_BOOT_SECTION macro used in the bootloader source code.

Unfortunately, that macro can't easily be applied to the inner library functions, so a bunch of flash in the bootloader space is taken up by (for example) the ISR handlers and USB control processing code. If there's enough interest I can add in a new compile time token to optionally move those over, but picking which functions to move could be a chore for the end-user. I've taken another look through the MAP file and can't see any easy targets I've missed, so the one quick fix I can suggest for now would be to use BOARD=NONE in your makefile to just disable the board LED drivers. It'll still work fine, but without the visual indicators.

- Dean

--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lufa-support...@googlegroups.com.
To post to this group, send email to lufa-s...@googlegroups.com.
Visit this group at https://groups.google.com/group/lufa-support.
For more options, visit https://groups.google.com/d/optout.

sv1...@gmail.com

unread,
Oct 1, 2016, 2:48:43 PM10/1/16
to LUFA Library Support List
Ok Dean,

Thank youfor taking the time to look into this.

I do also tried to use the BOARD NONE, but as I said it is also not working.
You can try it yourself too I guess.

What I did is to put the BOARD NONE in the mass storage bootloader firmware, then I just took another one of your examples, the bulk vendor, AS-IS, compiled it and fed it to the bootloader.
It accepted it yet when I re-started the chip, the loaded application (bulk vendor) did not work!!
On its own, without bootloader, the bulk vendor does work just fine.
(and as I said, this exact demo does work ok with DFU and CDC bootloaders)

If you see my previous port, I have attached the build logs of the BOARD NONE bootloader and from the bulk vendor application.

Thus, the problem remains, the mass storage bootloader does not work (though looks compile ok) even with BOARD NONE (as mentioned in the previous post)

So, please give it a go and make that test yourself and let me know if it works ok for you.

Thanks,
Christos

Garet Biglow

unread,
Jun 13, 2017, 5:19:44 PM6/13/17
to LUFA Library Support List
I'm having this overlap error as well:


MCU          = atmega32u4
ARCH         = AVR8
BOARD        = NONE

F_CPU        = 16000000
F_USB        = $(F_CPU)
OPTIMIZATION = s
TARGET       = BootloaderMassStorage
SRC          = $(TARGET).c Descriptors.c BootloaderAPI.c BootloaderAPITable.S Lib/SCSI.c Lib/VirtualFAT.c $(LUFA_SRC_USB) $(LUFA_SRC_USBCLASS)
LUFA_PATH    = ../../LUFA
CC_FLAGS     = -DUSE_LUFA_CONFIG_HEADER -IConfig/ -DBOOT_START_ADDR=$(BOOT_START_OFFSET)
LD_FLAGS     = -Wl,--section-start=.text=$(BOOT_START_OFFSET) $(BOOT_API_LD_FLAGS)

# device's fuses.
FLASH_SIZE_KB         = 32
BOOT_SECTION_SIZE_KB  = 4

yeilds this error on make:
c:/winavr/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: section .apitable_trampolines [00007fa0 -> 00007fb7] overlaps section .boot_aux.2 [00007e80 -> 00008121]

make: *** [BootloaderMassStorage.elf] Error 1

Any way this can be compiled? Dean?

Dean Camera

unread,
Jun 13, 2017, 9:14:51 PM6/13/17
to lufa-s...@googlegroups.com

I've just tried that configuration, and it compiles successfully for me on the latest LUFA HEAD (2cde257fe), using the latest Atmel Toolchain (avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 5.4.0).

You are using WinAVR which is positively *ancient* at this point - heck, I started with that nearly a decade ago, and it hasn't been updated for many, many years. I'd strongly suggest ditching it and switching to the latest toolchain instead for the bug fixes and better optimization support - there's a standalone version at http://www.atmel.com/tools/atmelavrtoolchainforwindows.aspx if you don't want all of Atmel Studio.


Cheers!

- Dean

Reply all
Reply to author
Forward
0 new messages