I was just looking at the bootloaders supplied with the 1.8.4 release of the IDE. Seems like they are still using a LUFA package back from 2011. Is that right?
Does anyone know if that's the version still being delivered in Arduino boards which have MCUs w/built in USB (e.g. Lilypad USB / atmega32u4)?
I discovered a side effect of these older bootloaders. It requires an unlikely chain of events:
If you happen to be using SRAM in your sketch at location 0x0800 and
Just happen to store the value 0x77 there, and
Then just happen to generate a WDT reset on the MCU...on purpose in my case...
Then the bootloader will not restart the sketch immediately but hang in the loader for 8 seconds before starting the sketch.
Yes, there's a lot of "luck" required to make this happen...but I did it and spent quite a while figuring out what was going on.
I notice that the newer LUFA loaders have fixed this problem. While I could work around this in the sketch, I'm tempted just to install a newer bootloader.
Can anyone provide some background on this issue? What's being delivered today and what's planned for the future?
There's another problem with this LUFA-based bootloader -- it is executing SPM instruction sequences with interrupts enabled. The chance of this causing a failure is pretty small because the timing requirements would be very tight -- but it will happen. I've submitted this as an issue on GitHub.
If anyone is interested, I've managed to get a bootloader running with the latest LUFA version (170418) and it is using the boot key value located at (RAMEND-1) where it won't trash any user data. While this is tweaked for the processor (ATmega32U4) and board I'm using, others may find it of some use. I'll be glad to share if anyone is interested.
One other point too. The bootloader can pass the initial value of MCUSR (i.e. cause of the reset) to the sketch in a MCU register, but there's still an ambiguity in the case of a WDT reset. This is because the Arduino core (CDC.spp) uses a WDT reset to start the bootloader when the COM port is touched at 1200 baud. If a sketch is also using the WDT to reset the MCU, this creates ambiguity. Who caused the WDT reset -- the core or the sketch? There's an easy solution to this: the bootloader can use one of the unused bits the copy of MCUSR passed to the sketch to resolve the ambiguity.
Seems like they are still using a LUFA package back from 2011. Is that right?
Seems that way to me too. Note that it's very intentional that the bootloader doesn't change very often, and it makes some sense that the libraries it uses change even less often.
(huh. I wasn't even aware that LUFA had been getting so many patches; I sort of thought it had been declared "done.")
Who caused the WDT reset -- the core or the sketch? There's an easy solution to this: the bootloader can use one of the unused bits the copy of MCUSR passed to the sketch
How does the bootloader TELL where the WDT happened?
I agree about not changing bootloaders too often. What I noticed is that the Arduino core has mods to work with a newer LUFA version, but they've never updated the bootloader to use the new LUFA (at least where Caterina is concerned). Nothing wrong with that, it's just something I noticed.
Regarding forensics on WDT resets:
AFAICT, between sketch, Arduino core (CDC.cpp) and the bootloader, there are only two ways a WDT reset can occur.
Core causes it intentionally after COM port is touched at 1200 baud, and sets bootKey = 0x7777
Sketch causes it (may or may not be intentional) and presumably does not set the bootKey
With the new core, bootKey is at (RAMEND-1) and there's no chance the sketch will have data located there.
So, when you get into the bootloader, if the bootKey is 0x7777 then you may conclude it was caused by the core and not the sketch. While the bootloader can't tell "where" the WDT happened it can tell if it was caused by the core.
If you want to get picky, the sketch COULD set the bootKey itself prior to generating WDT reset and then you can no longer tell the difference. Some might consider this a feature -- it provides a way for the sketch to force the bootloader by setting bootKey and generating WDT reset (not that I know why you'd want to do that).
There may be a better way to cook this information into a bit passed to the sketch, but that's what occurred to me.