Re: [LUFA Support : 3843] Leonardo bootloader won't program

351 views
Skip to first unread message

Don Davis

unread,
Jan 15, 2013, 2:39:25 PM1/15/13
to lufa-s...@googlegroups.com
That doesnt seem to be a bug. It is the trick they use to soft enter the bootloader, it also has nothing to do with lufa. Please continue this on the arduino forum.

On Tue, Jan 15, 2013 at 11:20 AM, Mike King <mkw...@gmail.com> wrote:
I found a bug in the Arduino Leonardo bootloader.  This code is based on the LUFA codebase.  I have reviewed the current LUFA release, and it has a similar problem.  The details are different but the concept is the same.  Check out the linked post below for more information.


--
You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/lufa-support/-/u4c-o6Epmm4J.
To post to this group, send email to lufa-s...@googlegroups.com.
To unsubscribe from this group, send email to lufa-support...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lufa-support?hl=en.

Mike King

unread,
Jan 15, 2013, 2:57:54 PM1/15/13
to lufa-s...@googlegroups.com
I don't agree with the statement that it has nothing to do with LUFA.  Yes, the code is different than the code in LUFA, but the problem is the same.  The non-bootloader code can modify the MagicBootKey variable.  I agree that this may not be a problem in the LUFA environment.  The worst that can happen is that the watchdog timer causes the bootloader to run after reset instead jumping back to the non-bootloader code which may not be a problem.

Jim Paris

unread,
Jan 15, 2013, 3:30:34 PM1/15/13
to Mike King, lufa-s...@googlegroups.com
Usually, a bootloader key like that is configured immediately before
triggering a watchdog reset. The typical sequence is:

- disable interrupts
- set bootloader key
- enable WDT
- busy loop until WDT reset hits

The real bug in Arduino is that they set the key to 0x7777 (in
hardware/arduino/cores/arduino/CDC.cpp) and enable the watchdog timer,
but then they just continue on executing, with interrupts enabled, so
you have a 120ms window where the bootloader key can get clobbered by
something else (and clobbering whatever variable used to be there, in
the process). They even allow the host to "cancel" the bootloader
request and set the key back to 0.

Clearly this is a bug in arduino: they could either:

- actually reserve the location like you suggested

or:

- when DTR goes low, start a 120ms software timer
- if the DTR goes high before the timeout, reset that software timer
- when the 120ms software timer expires, then do the sequence
listed above to trigger the actual WDT reset into the bootloader

However, I definitely agree with Don Davis that this is unrelated to
LUFA. How you trigger the bootloader is up to the application layer,
in this case Arduino code.

-jim

Mike King wrote:
> I don't agree with the statement that it has nothing to do with LUFA. Yes,
> the code is different than the code in LUFA, but the problem is the same.
> The non-bootloader code can modify the MagicBootKey variable. I agree
> that this may not be a problem in the LUFA environment. The worst that can
> happen is that the watchdog timer causes the bootloader to run after reset
> instead jumping back to the non-bootloader code which may not be a problem.
>
> On Tuesday, January 15, 2013 2:39:25 PM UTC-5, feurig wrote:
> >
> > That doesnt seem to be a bug. It is the trick they use to soft enter the
> > bootloader, it also has nothing to do with lufa. Please continue this on
> > the arduino forum.
> >
> > On Tue, Jan 15, 2013 at 11:20 AM, Mike King <mkw...@gmail.com<javascript:>
> > > wrote:
> >
> >> I found a bug in the Arduino Leonardo bootloader. This code is based on
> >> the LUFA codebase. I have reviewed the current LUFA release, and it has a
> >> similar problem. The details are different but the concept is the same.
> >> Check out the linked post below for more information.
> >>
> >> http://arduino.cc/forum/index.php?topic=141812.msg1064572
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "LUFA Library Support List" group.
> >> To view this discussion on the web visit
> >> https://groups.google.com/d/msg/lufa-support/-/u4c-o6Epmm4J.
> >> To post to this group, send email to lufa-s...@googlegroups.com<javascript:>
> >> .
> >> To unsubscribe from this group, send email to
> >> lufa-support...@googlegroups.com <javascript:>.
> >> For more options, visit this group at
> >> http://groups.google.com/group/lufa-support?hl=en.
> >>
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups "LUFA Library Support List" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/lufa-support/-/cgJAtwCbxWoJ.

Mike King

unread,
Jan 15, 2013, 3:47:58 PM1/15/13
to lufa-s...@googlegroups.com, Mike King
I agree with your analysis of the Arduino codebase.  But I think my statement is still valid.  I won't bother the group with this anymore.
Reply all
Reply to author
Forward
0 new messages