Delay at the end of bootloader code?

A shrunk down Leonardo-compatible board, thumb drive sized with native USB support. [Product info]
Post Reply
Posts: 1
Joined: Tue Dec 23, 2014 6:19 pm

Delay at the end of bootloader code?

Post by yancheelo » Tue Dec 23, 2014 6:29 pm

Hi all,
I am new to this forum hence hello to everybody.
I was playing with atMega32u4 on LeoStick, when I had some issue on making the Teensy example working on my board and my PC (Win8). The USB device (mouse, keyb, etc.) did not get enumerated, but only the bootloader.

I have fixed the issue (after struggling some days) by simply adding a delay of some ms (I have chosen 100ms) at the beginning of the sketch.
Actually, on the ATmegaU32 data sheet we can see:

"22.9 Detach
The reset value of the DETACH bit is 1.
It is possible to re-enumerate a device, simply by setting and clearing the DETACH bit (but firmware must take
in account a debouncing delay of some milliseconds)."

Maybe it would be worth to add a delay after the USB detach and before starting the sketch to avoid such issues, like below:

while (RunBootloader)
/* Time out and start the sketch if one is present */
if (Timeout > TIMEOUT_PERIOD)
RunBootloader = false;


/* Disconnect from the host - USB interface will be reset later along with the AVR */

/* Add a de-bouncing delay of some ms according to AT mega technical doc */

/* Jump to beginning of application space to run the sketch - do not reset */



Freetronics Staff
Freetronics Staff
Posts: 853
Joined: Tue Apr 09, 2013 11:19 pm
Location: Melbourne, Australia

Re: Delay at the end of bootloader code?

Post by angusgr » Fri Feb 27, 2015 1:31 am

Hi yancheelo,

Thanks for reporting this. Sorry I never replied before now.

I've encountered this problem occasionally as well on Windows. I just pushed out a new "V2.1" bootloader than includes a fix based on yours, seems to solve the problem:

Fix commit: ... 0091417c3e

Be interested to know if that fix also works for you. Thanks again for the heads-up on this.

Post Reply