Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
microcom
PostPosted: Feb 28, 2013 - 09:21 PM
Rookie


Joined: Feb 25, 2012
Posts: 22


Hi!

I just soldered together my custom ATmega32U4 AVR dev board. It has a USB connector on it, a reset button, and HWB is tied to ground.

I've successfully managed to flash the software with the DFU bootloader, but on reset I always have to start the programmer with
Code:
dfu-programmer mega32u4 start
...my code won't run on reset; it must be started through the terminal.

I know this problem is because I tied HWB to ground... but is there any way (with fuses or other bootloaders) to get the bootloader to run for a very short time on reset, then start the program... basically, the reset would look like this:
1. Jump into DFU bootload mode
2. Wait 1 second
3. Start program

This functionality is kind of like the Arduino's bootloader.

How could I accomplish this?


Thanks in advance!
Michael
 
 View user's profile Send private message  
Reply with quote Back to top
lincoln
PostPosted: Mar 01, 2013 - 12:22 AM
Hangaround


Joined: Jul 22, 2011
Posts: 150
Location: San jose, CA, USA

Well there is a data sheet for the DFU boot loader, might look there for options. Also could use the Arduino boot loader. Or albeit a non trivial task, write your own.

_________________
link

i am a NOOO00B!!

Don’t let that undermine what I just said.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
clawson
PostPosted: Mar 01, 2013 - 10:11 AM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71738
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

I know this problem is because I tied HWB to ground...

Oops.
Quote:

but is there any way (with fuses or other bootloaders) to get the bootloader to run for a very short time on reset,

The reason the USB AVRs have HWB while the tiny/mega don't is because in the case of a non USB chip that has a bootloader you can set the BOOTRST fuse and execution always starts ni the bootloader. It can enable UART (or whatever the comms interface is) and listen for a while and then, if it decides no code is coming can happily carry on into the application with no harm done.

USB is a bit different. If (as you've arranged here because of HWB=0) the USB chip always starts into the bootloader then on enabling the USB interface the very first thing that's going to happen is that it will enumerate with the PC. It will say "I'm a HID/generic/whatever class device and I want to talk". So the PC will load support for that HID/Generic/whatever interface. Now if after 5 seconds (or whatever) there's nothing forthcoming to say "lets do the f/w update thing" it has to enter the app code. But it's already connected to the PC and enumerated as a DFU. So now there has to be a USB reset and then the app code enumerates as something else (CDC or whatever). This would be "messy". When you use "dfu-programmer mega32u4 start" you are, indeed, telling it to do just this. It stops being a DFu and starts being a CDC or whatever. This is unlike the UART bootloader case where it can enable the UART, listen for a bit, then close down the UART and no one noticed. That's why mega's can have BOOTRST set all the time and always start into the bootloader.

That's why HWB exists. The plan is that at start up it normally just enters the app code and immediately enumerates as your chosen (CDC or whatever) device. On the occasions you want to update the code the user is invited to hold down a button at power on, this connects the HWB pin to Gnd and this time the code starts in the bootloader and enumerates as DFU.

I guess you could take the source of DFU and modify it slightly so that if, for example it starts and does not find a value in an EEPROM location that says "do the f/w update thing" it just does a "JMP 0" to enter the app. So the USB interface is not touched. But you cannot use DFU "as is" without some modification along these lines.

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
microcom
PostPosted: Mar 01, 2013 - 10:26 AM
Rookie


Joined: Feb 25, 2012
Posts: 22


Ah, so that's how the bootloader works. Thanks for the explanation... I tried to go through Atmel's datasheets to learn more about HWB, but I just found this cryptic explanation:
Quote:
The Hardware Boot Enable fuse (HWBE) can be
programmed so that upon special hardware conditions under reset, the bootloader execution is forced after reset.


I connected HWB to ground not by mistake, however. I based my board's design off of Sparkfun's ATmega32u4 breakout board, which has HWB tied to ground:
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/AVR/32U4_Breakout-v11.pdf

Their product page https://www.sparkfun.com/products/11117 states:
Quote:
The board comes pre-loaded with the LUFA CDC bootloader... If you have an application already on the IC and you want to reprogram, simply press the on-board reset button and the bootloader will run for 7 seconds to allow time for programming.


So it looks like I might want to use LUFA CDC. How would I go about overwriting the DFU bootloader and replacing it with LUFA? Can I just
Code:
make && dfu-programmer mega32u4 erase && dfu-programmer mega32u4 flash BootloaderCDC.hex
? Or do I have to do something special to overwrite the DFU bootloader?

Thanks for the help!
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Mar 01, 2013 - 12:39 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 71738
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Or do I have to do something special to overwrite the DFU bootloader?

You need an ISP/JTAG programmer. A bootloader (DFU) cannot over-write itself with another one (LUFA-CDC).

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits