Does anyone know if Atmel supplies the HEX file for the factory-programmed DFU bootloader supplied with the AT90USB1286?
(I know the AT90USB162 HEX is available - bl_usb_162v105.zip)
Bit of an update:
I have another board with an AT90USB1286 which still has the AVR DFU on it. I attempted to reflash another blank AT90USB1286 to get the DFU on it by doing the following:
1. Read flash of the AT90 with the DFU on it using Atmel Studio 6 (with a JTAGICE mkII), save HEX.
2. Flash blank AT90 with HEX read in Step 1.
3. Ensure correct fuse bits set in freshly flashed AT90: HWBE set, CKDIV8 set.
Seems so simple, but the DFU fails to work in the second board.
Code protection bits are set on the 'master' chip you are trying to read?
BTW, I've never been able to find a stock atmel replacement DFU .hex file for the newer USB chips.
If you do find one, please post the link.
Found the AVR DFU bootloader HEX file for the AT90USB128x:
Just tested and verified then with Flip 3.4.7 :)
This thread lead me to it: https://www.avrfreaks.net/index.p...
They keep bouncing around the Atmel website pages - they used to be in the device specific pages, then they were moved to the FLIP page, and now I've no idea where they ended up. Ask the support line, they will be able to find the most up to date HEX files for you.
Alternatively, I have a set of precompiled bootloaders using LUFA that are compatible with FLIP here:
- Dean :twisted:
Make Atmel Studio better with my free extensions. Open source and feedback welcome!
Quick follow up.
I dropped the Atmel support line a request about the where to find the stock DFU bootloaders.
They emailed me the files for the chips I needed. So they may not currently be available for direct download, but they are available from support (thank you support).
Dean, I'd normally just use the LUFA versions but then I'd have to supply documentation for the bootloader. If I can restore the factory bootloader to the chip I can then just point to Atmel for docs.
Hello, I did not manage to get a working working bootloader for a TEENSY++2.0 resp. an at90usb1286 with the current LUFA version from https://github.com/abcminiuser/l... (hash: 2cde257fe11886bebbfe4aea816268c2739d89bb). I modified the make file like this:
# LUFA Library
# Copyright (C) Dean Camera, 2017.
# dean [at] fourwalledcubicle [dot] com
# LUFA Project Makefile.
# Run "make help" for target help.
MCU = at90usb1286
ARCH = AVR8
BOARD = TEENSY2
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 -DBOOT_START_ADDR=$(BOOT_START_OFFSET) -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 := 128
BOOT_SECTION_SIZE_KB := 8
# Fuse Settings
# Extended: 0xF3
# High: 0xD9
# Low: 0x5F
# Lock Settings
# Lock Bit= 0xFF
# Bootloader address calculation formulas
# Do not modify these macros, but rather modify the dependent values above.
CALC_ADDRESS_IN_HEX = $(shell printf "0x%X" $$(( $(1) )) )
BOOT_START_OFFSET = $(call CALC_ADDRESS_IN_HEX, ($(FLASH_SIZE_KB) - $(BOOT_SECTION_SIZE_KB)) * 1024 )
BOOT_SEC_OFFSET = $(call CALC_ADDRESS_IN_HEX, ($(FLASH_SIZE_KB) * 1024) - ($(strip $(1))) )
# Default target
# Include LUFA-specific DMBS extension modules
DMBS_LUFA_PATH ?= $(LUFA_PATH)/Build/LUFA
# Include common DMBS build system modules
DMBS_PATH ?= $(LUFA_PATH)/Build/DMBS/DMBS
The fuse bits setting is:
Lock Bit= 0xFF
But unfortunately the Bootloader does not work. I was not able to flash with avrdude, also. It only worked with the ATMEL Studio (v.7).
I tried this on my linux workstation:
avrdude -p at90usb1286 -P usb -c avrispmkII -U flash:w:./HID/BootloaderHID.hex:i
But this leads to an empty flash. Do I have to give a special parameter that avrdude write to the bootloader section?
I attached the resulting hex file. If I understand it right the bootloader code start at address 0x0E00, but it should be 0xF000.
It would be nice if I get help with that issue.
© 2019 Microchip Technology Inc.