Any way to launch the LUFA DFU bootloader programmatically (e.g using a vendor command)?

[Chris McClelland]

Hi LUFA'ers,

I have an AT90USB162 board where the HWB line is not easily accessible. What I'd like to be able to to is do a one-time AVRISP-flash of my application plus the LUFA DFU bootloader, where my application has a vendor command that stops the application running and starts the bootloader, as if I've manually done a HWB+RESET. Subsequent application updates can then be done without the AVRISP connected - indeed, without even touching the board.

Is that possible?

Chris

[László Monda]

Hey Chris,

This is definitely possible.

Here's how you can enter the bootloader via software:
http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__software_bootloader_start.html

First you're supposed to ISP-flash the DFU bootloader and then
DFU-flash your own firmware as many times as you'd like. DFU also has
a restart command which you can use after DFU-flashing your firmware
to start it.

You could also merge the DFU bootloader and your firmware and
ISP-program the whole shebang at one as described at
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=33291&start=0
but because of the added complexity I'd only do it when mass
programing boards.

> --
> You received this message because you are subscribed to the Google Groups
> "LUFA Library Support List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to lufa-support...@googlegroups.com.
> To post to this group, send email to lufa-s...@googlegroups.com.
> Visit this group at http://groups.google.com/group/lufa-support.
> For more options, visit https://groups.google.com/groups/opt_out.



--
László Monda <http://Monda.hu> | <http://UltimateHackingKeyboard.com>

[Nicolas Saugnier]

Hello,

I don't know the AT90USB162, but on the ATmegaXXu2 and XXu4 at least, there is a factory programmed DFU bootloader that takes 4k. It runs by default as long as the chip has not been programmed at least once, so you don't even need to do a first programation through ICSP. After that you can run it again in software as you mentioned.

I have done so just a week ago with success, on a board where I use the same command to reboot in bootloader mode as the Ardunio Leonardo (open the CDC/ACM serial portat 1200bps then close it).

Best

2013/10/29 László Monda <la...@monda.hu>

[Donald Delmar Davis]

Nicolas,

How were you able to keep it in the stock bootloader? Does it have a leave a cookie mechanism like the catrina or deans?

That would be sweet to have the stuff work out of the box and be able to jump to the bootloader in software. 

I experimented with that but was unsuccessful and am now running the catrina (sparkfuns variant) on my u4 based midi boards.

Don.

[Chris McClelland]

Köszi szépen, László! This is exactly what I wanted. I'll try it tomorrow.

Xevel, thanks for your reply too. That's exactly what I normally do with my own AVR boards (although I always just use the HWB+RESET sequence). Unfortunately in this case the board is a 3rd-party commercial thing[1] that I'm hacking to replace the stock firmware with FPGALink/AVR firmware[2]. The board manufacturer erased the DFU bootloader, so an initial AVRISP load is necessary.

Chris

[1]http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/iCEblink40HX1KEvaluationKit.aspx
[2]http://www.makestuff.eu/wordpress/software/fpgalink/

[Nicolas Saugnier]

Chris:

Ok, sorry about that, that possibility did not even cross my mind. Glad you have your answer though :)

Don: 

I am not 100% sure I understand your question. Not exactly sure what you mean by "coockie mechanism" in this context.

My experience has been that things DO work out of the box: I assemble a board, plug it in the USB port (it enumerates as a DFU compatible device thanks to the stock bootloader), run FLIP or DFU-programmer and flash my firmware. Nothing more needed until I want to update: I trigger the software reset+bootloader mechanism according to Dean's doc that has been linked to previously, and re-program the MCU with the new firmware.

Best,

Nicolas

2013/10/29 Chris McClelland <proph...@gmail.com>

[Donald Delmar Davis]

Nicolas,

I didnt understand that the "magic boot key" worked with the stock bootloader. 

Thanks!

Don.

[Nicolas Saugnier]

OK, now I see. 

The magic boot key is a trick used for the MCU to know if we want it to run the normal program or the bootloader after a reset - and that is the case whatever bootloader exists in the memory. It is a part of the user program, and only exists after the first time it has been flashed with a firmware defining it. Its value has no importance whatsoever, it is used as a "dead-letter box" that the firmware leaves to itself to read after the reset that erases all of its memory blocks (except this one, hence the ATTR_NO_INIT next to boot_key).

Also, it has nothing to do with the fact that the bootloader runs out of the box, but I have to admit that my knowledge of the boot mechanism does not extend far enough to explain it.

Best,

Nicolas

2013/10/29 Donald Delmar Davis <ddelma...@gmail.com>

[Chris McClelland]

OK so on my iCEblink40 board, in order to get it to work, I had to make these changes:

* In Jump_To_Bootloader(), I move Boot_Key=MAGIC_BOOT_KEY before the call to USB_Disable().

* In Bootloader_Jump_Check(), I comment out the (MCUSR&(1<<WDRF)) condition.

I investigated further: if I comment out Bootloader_Jump_Check() altogether, then a call to Jump_To_Bootloader() just resets my firmware rather than starting the bootloader, allowing me to query MCUSR, and I notice that after a Jump_To_Bootloader()-induced reset, MCUSR always reports a brownout condition rather than a watchdog reset. It seems like the call to USB_Disable() is causing the power to fail. Is this expected behaviour for an AVR which draws power from USB in order to power itself via its internal 3.3V regulator (i.e UVCC connected to USB +5V, and VCAP, VCC & AVCC connected together as per fig. 7.2 in the at90usb162 datasheet)?

Can anyone think of any pitfalls with my workaround described above? I haven't seen it happen, but I guess if the call to USB_Disable() is causing the power to fail, it's possible the magic number stored in Boot_Key could be corrupted before Bootloader_Jump_Check() runs? Also from the host's perspective, the disconnect-reconnect cycle is a lot faster than the 2000ms specified in the original code. Linux detects the change nicely, but maybe other platforms will have problems? Any alternative workarounds?

BTW, the original Jump_To_Bootloader() and Bootloader_Jump_Check() code works perfectly on an externally-powered AVR. I haven't tried it yet on an AVR powered at 5V from USB (i.e regulator unused).

Thanks!

Chris

[László Monda]

I tried out the bootloader check code a while ago and it worked well
on one of my AVR development boards when I USB-powered it.

Unfortunately, I don't have any ideas why the brown out condition
occurs on your board.

When I googled for "iCEblink40" I found an FPGA board that has nothing
to do with AVRs. Am I mistaken?

[Chris McClelland]

> When I googled for "iCEblink40" I found an FPGA board that has nothing
> to do with AVRs.  Am I mistaken?

The iCEblink40 is an FPGA board which uses an AT90USB162 for programming the FPGA. The AVR also provides an EPP-like connection to the FPGA for transferring arbitrary binary data. What I have done is to overwrite the stock AVR firmware with the LUFA-based FPGALink[1] AVR firmware. And it works perfectly, apart from this minor anomaly with the brownout when I trigger the bootloader. I will try to replicate the behaviour with a standalone AT90USB162 in an electrical environment that closely matches that of the AVR on the iCEblink40.

Chris

[1] The aim of the FPGALink project is to provide a hardware abstraction layer for hardware involving an FPGA connected to a computer over USB, to abstract core functionality like FPGA-programming and subsequent host<->FPGA communication. It doesn't matter whether the hardware uses an AVR, a Cypress FX2 or an ARM-based micro or whatever for its USB interface. It doesn't matter whether the FPGA is from Xilinx or Altera or Lattice or whomever. It doesn't matter whether the interface between them is a fast 43MiB/s parallel synchronous interface, a much slower EPP interface or come sort of USART connection. The cross-platform host-side API is the same, and the FPGA-side FIFO-interface API (in VHDL and Verilog) is the same.
https://www.ohloh.net/p/fpgalink
http://www.makestuff.eu/wordpress/software/fpgalink/

[pub...@hansmi.ch]

Am Freitag, 1. November 2013 02:05:58 UTC+1 schrieb Chris McClelland:

I haven't seen it happen, but I guess if the call to USB_Disable() is causing the power to fail, […]

Yes, it does by disabling the 3.3V regulator. This is now fixable with a new flag added to the master branch (commit 25a02432e).

Michael