LUFA + Teensyduino?

[Garet Biglow]

Hello everyone,

I have been trying to get LUFA working with the Teensyduino environment for the past few weeks and haven't had much success. I'm not sure if the following is correct:

My understanding is that I can load the LUFA HID bootloader and it will mimic the HalfKay bootloader that Paul puts out on his Teensy 2.0. This would allow me to upload code via Teensyduino + the Teensy GUI loader over USB.

I believe this because of the following article:

http://elasticsheep.com/2010/01/installing-the-lufa-teensyhid-bootloader/

I am trying to replicate the steps in this article, just using an atmega32u4 (making the appropriate changes of course).

I have been able to upload the LUFA HID bootloader onto the chip, and it comes up in windows as a "USB Input Device". Good news i suppose, but when I try to upload a .hex file with Teensyduino + Teensy loader, it doesn't recognize the chip. I have done the following steps to get to this point:

1. Set the hfuse, lfuse, efuse (0x5E, 0x99, 0xF3 determined using an online fuse calculator and uploaded via AVRDUDE)
2. Altered the make file to include the correct MCU, clock freq, bootloader size, and total size (atmega32u4, 16MHz, 4k, 32k)
3. Used the make command to compile the make file
4. Uploaded the bootloader (avrdude -p atmega32u4 -c avrispmkii -P usb -U flash:w:bootloaderhid.hex)

Any ideas, comments, or help would be greatly appreciated. Thanks very much in advance!

[Dean Camera]

Hi Garet,

As stated in the accompanying text file (which is built into the bootloader documentation if you run it through Doxygen):

"This bootloader is deliberatley non-compatible with the proprietary PJRC HalfKay bootloader GUI; only the command line interface software accompanying this bootloader will work with it."

The original release of it did indeed work with Paul's TeensyHID GUI, however after he requested I remove the compatibility code (as it was diminishing his business, quite understandably) the latest releases work with the modified command line interface programmer only. While of course having the nice GUI is preferable, I don't want to be responsible for Paul going broke from no one buying his Teensy boards anymore, as China was producing clones en-masse with my code in them and selling them as the genuine item.

Cheers!
- Dean

--
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.

[mitchjs]

slightly off topic (and maybe slightly on)

what we really need is someone to code some nice GUIs for boot loaders...

using command line, isn't what computers are about (sorry Linux people)

programmers use command line, but the non-programmers expect GUI

if I put out a product that might need a firmware update, and I expect the END

user to do the update, it has to be GUI, and almost 1 click!

right now, I got one product, that im having them use the Atmel Flip application

its GUI, too many clicks, but at least I can walk one through it....

yes, I have done batch/cmd files to do simplify programming, vut that's for production

not in the field

my 2cents

cheers to Teensy Loader's simplicity!

mitch

(ok I know someone is going to say, so write a GUI for boot loaders (HID/DFU/CDC) )

(I prob could, but im not that good of a windows programmer, and maybe one in something that could run on mac/Linux too)

[Michael Hennebry]

On Sat, 22 Feb 2014, mitchjs wrote:

> what we really need is someone to code some nice GUIs for boot loaders...
> using command line, isn't what computers are about (sorry Linux people)
> programmers use command line, but the non-programmers expect GUI

GUI's are popular with Linux people as well.
Some of us, not enough of us, object to the notion that
because something has a GUI, it does not need documentation.

Also, 'tis hard to write a script for a GUI.

--
Michael henn...@web.cs.ndsu.NoDak.edu
"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

[Jonathan Carron]

Hi Dean,

 

Would you be able to elaborate a bit on this? I too have a atmega32U4, and am using the teensy loader; but say I program the board to for something simple, to flash a LED on/off - when I program the board, (it says programming, done), there is nothing working. The teensy loader does seem to talk to it, as when I issue the 'reset' command it resets the microprocessor via the only connection I have to it (USB). I also see 2 USB compatible devices with the expected VID/PID on the USB bus.

 

Now, if I program that same HEX to the atmega32U4 via 'programmer' using the MSIO and MOSI SCLK lines, it works fine.

 

I did l compile and burn the appropriate boot loader into the chip. I've tried various fuse settings to no avail.

 

In terms of doing things properly... I am using a older LUFA code release, which using the newer teensy loader is no longer possible, if I were to use the newer one, I would need to use the teensy command line loader, from my understanding, which is OK. Could you share which of the 3 boot loaders I'd pick?

 

Thanks,

 

Jonathan

[Dean Camera]

Jonathan (assuming you haven't died of old age by now),

I'm not sure why the Teensy Loader UI isn't working, but as I don't officially support it anymore I don't really want to start debugging it, since Paul would prefer it was used on his genuine Teeny boards only. It's possible Paul has changed the algorithms in the loader to detect the "counterfeit" bootloader but more than likely it's just crusty code failing on newer systems.

If you want to use the latest release, you would need to compile and use the included CLI application, which is just a tiny modification from Paul's sample code. You should compile the Bootloaders/HID/ directory for your part or just grab the appropriate binary here:

http://fourwalledcubicle.com/files/LUFA/Bootloaders/

Then use either the Bootloaders/HID/HostLoaderApp/ or the Bootloaders/HID/HostLoaderApp_Python CLI frontends. The latter is my own simple Python based front-end programming software for the bootloader.

Cheers!
- Dean

For more options, visit https://groups.google.com/d/optout.

[zachary dickerson]

I am in need of a GUI for the atmega32U4  using a LUFA bootloader or Arduino based loader, anything that is point/click to upload a hex file for customers.  We intend to buy chips for teensy3.1 but the other product will use teensy2/pro-micro.  I just need a nice GUI for users to update, the command line version is NOT an option for a product and is blocking progress.  The chips are too pricey for the product of this price range.  Any options would be awesome.  I can only find documentation about Atmel Flip at this time, and that does not look very friendly compared to teensy2 gui...  We are willing to pay for an option if it comes to this, please let me know.

[Dean Camera]

Hi Zachary,

Sorry for the late reply. I don't know of any free GUI based bootloaders other than the DFU one, but if your customers will struggle with a CLI utility I don't think they would find FLIP any nicer as you've already surmised.

One suggestion would be to modify my HID bootloader's Python updater utility to take a HEX as a first argument, and then compile that into a native executable using http://www.py2exe.org/. That would give you a simple EXE that users could just drag-and-drop a HEX file onto to reprogram the board.

Cheers
- Dean

[Jonathan Carron]

Hi Dean

I've been messing about with this for a little while trying to get a
wee bit further as time progresses. I've flashed the included hex from
lufa-140928/Bootloaders/MassStorage/MassStorage-AVR8-atmega32u4-BOARD_NONE-BOOT_4KB-16MHz.hex
to the 32u4 I have.

I get a USB mass storage device on the PC when I plug it in via USB
... But when I try and upload a simple sketch, using my ASP programmer
(compile code in Arduino & copy .hex + flash with avr_dude) it seems
to "ZAP" the boot loader and just upload the sketch... :( meaning mass
storage device goes away, and led starts blinking per the below
code....

Example of said simple sketch:
const int ledPin = 9;

void setup() {
pinMode(ledPin, OUTPUT);
}

void loop() {
digitalWrite(ledPin, HIGH);
delay(1000);
digitalWrite(ledPin, LOW);
delay(1000);
}

So, I suspect I'm doing something very wrong... Also I'm beginning to
think I have misunderstood what the point of the mass-storage boot
loader is, that its actually in fact used for copying over the .hex or
.'c' code to run on the device?... im sort of lost.

What I want to try and do is basically turn the 32u4 into a flash
drive, using a sdmicro card, and have it identify its self with
different VID and PID values and strings... eg HP 100W 2 gb flash
drive.

I'm hoping to run a ext2 or UFS filesystem on this, but from what I
can see there's only libraries for FAT related..?

Any advice or guidance would be awesome

Thanks,

Jonathan

[Dean Camera]

Joanthan,

<Insert Jumunji "WHAT YEAR IS IT?" meme here, since I looked at the last reply date>

The Mass Storage bootloader allows you to reprogram the AVR with your own program, by dragging and dropping a specially named ".BIN" file over the top of the virtual flash and EEPROM files it exposes. It's a tool to make reprogramming boards easier for people rather than messing around with virtual COM ports, AVR109 based programming tools, or external programmers.

I just realized the accompanying documentation for it is a bit rough, so I'll extend it now with details on how to use it. Specifically, you should compile your program as-normal to get a .HEX file output. Some build systems will also produce a .BIN file for you, but if not you can convert it via the terminal. Here's the new additional text:

=====================

The current device firmware can be read from the device by reading a file from the virtual FAT filesystem. Two files will be present:

• FLASH.BIN, representing the AVR's internal flash memory
• EEPROM.BIN, representing the AVR's internal EEPROM memory

To convert an existing Intel HEX (.HEX) program file to a binary (.BIN) file suitable for this bootloader, run:

    avr-objcopy -O binary -R .eeprom -R .fuse -R .lock -R .signature input.hex output.bin

From a terminal, replacing input.hex and output.bin with the respective input and output filenames. AVR EEPROM data files in Intel HEX format (.EEP) uses a similar technique:

    avr-objcopy -O binary input.eep output.bin

=====================

To make a flash drive like you want, use the Demos/ClassDriver/MassStorage demo. As-is the demo is expecting an Adesto Dataflash (formerly Atmel Dataflash) memory IC to be connected as a backing store, but you can substitute a SD Card block read/write driver from ELM Chan's FATFS demo or similar. Note that you don't actually need a FAT driver, since the USB Mass Storage device doesn't necessarily need to care *what* data is being written and read, and just needs to manage the raw data blocks irrespective of any filesystem.

- Dean

[Jonathan Carron]

Hi Dean

hah has been a while since I last wrote, I didn't actually realize it had been almost a year. Wow! I better get moving on this before I die of old age...

Thanks for the notes below on how to properly use that!

Will look into ELM Chans fat driver and see how far I can get.

Cheers

Jonathan