[Solved] Atmega32u4 with Arduino Bootloader crashes with Arduino IDE

Other Hardware 3rd Party Boards
1

We've spun some boards for a wireless charger project, copying the Arduino Micro schematic for a lot of the power and connections (HWB with pulldown, Reset with pullup, etc.)

Using Atmel Studio and ISP, I loaded in the Arduino Micro bootloader. Looks good, pops up in the Device Manager as a Micro.

Testing with a simple Blink program (tested as working on a stock Micro), I hit upload, the progress bar fills up, pause, then:

Arduino: 1.8.5 (Windows 7), Board: "Arduino/Genuino Micro"...
...
Forcing reset using 1200bps open/close on port COM43
PORTS {COM1, COM43, } / {COM1, COM43, } => {}
PORTS {COM1, COM43, } / {COM1, COM43, } => {}...
...
PORTS {COM1, COM43, } / {COM1, COM43, } => {}
PORTS {COM1, COM43, } / {COM1, COM43, } => {}
PORTS {COM1, COM43, } / {COM1, COM43, } => {}
PORTS {COM1, COM43, } / {COM1, } => {}
PORTS {COM1, } / {COM1, } => {}
PORTS {COM1, } / {COM1, } => {}
PORTS {COM1, } / {COM1, } => {}...
...
Couldn't find a Board on the selected port. Check that you have the correct port selected. If it is correct, try pressing the board's reset button after initiating the upload.

And it disappears from the Device Manager until I unplug the USB and plug it back in again. I monitored the 5V supply, thinking maybe there was a dip. Nope, solid 5V on the 'scope.

I looked at the hex file. It's still the bootloader code, no Blink code in there. And of course, it's not blinking.

The problem seems to center around the IDE, and programming via USB. I can program happily via ISP, with my Atmel charger code working well. (I'm switching the code over to Arduino for the ability to do USB firmware updates in the field without having to muck about with Atmel's oddly unsophisticated bootloader, or going down the LUFA rabbithole. There are only so many hours I can bill to my employer for learning new tricks :slight_smile: )

Any ideas?

2

New... clues? I got the unit to program one time by lucky timing in grounding the reset pin. Obviously that's not going to fly in the field. Plus, I was batting around one for twenty.

I can set the fuses to the values I read in the Micro (low 0xFF, high 0xDB, ext 0xCB). But when I Read them again, the extended fuses Read 0xFF (no HWBE, 2.6V brownout). That's the same settings as the Micro, but the Micro's extended fuses Read as 0xCB. Weird?!

Is it some weird timing thing, transitioning from bootloader? I've built three boards, and they all act the same way (not like the stock Micro).

3

I believe you need to compile your (application) code with the Arduino IDE in order for the transfer to the bootloader to work. Also if you use the IDE to install the bootloader the fuses will be set correctly during the installation.

Edit: Do you have an Led on "Pin 13" (PC7)?
When you press and release reset the Led will pulse for ~8 seconds while the bootloader runs (you may have to double tap reset). With the bootloader running you should be able to upload your program.

4

Thanks for the response.

There's a good clue. I can load in the bootloader with AtmelICE via ARM ISP, and the contents read the same as the Micro, which I erased, then loaded the same bootloader into (and still works as expected). But when I try to use the IDE to load the bootloader, I get

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega32u4 -catmelice_isp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xfb:m -Uhfuse:w:0xd8:m -Ulfuse:w:0xff:m

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch

System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

Using Port : usb
Using Programmer : atmelice_isp
avrdude: jtag3_open_common(): Did not find any device matching VID 0x03eb and PID list: 0x2141

avrdude done. Thank you.

Error while burning bootloader.

I'll monitor PC7 and see what's going on there. I don't have anything connected to it.

(By the way, I did compile the Blink sketch with the IDE.)

5

Could it be a problem with the IDE somehow not seeing the programmer? It's definitely looking for it, and the VID and PID are correct in Device Manager. But "Burn Bootloader" doesn't work with either the Atmel-ICE or and JTAGice3. Similar failure report:

Using Port : usb
Using Programmer : jtag3isp
avrdude: jtag3_open_common(): Did not find any device matching VID 0x03eb and PID list: 0x2110, 0x2140

Am I missing something basic in the Burn Bootloader thing? I chose the board (Genuino Micro), the tool (AtmelICE-ARM or JTAG-ICE3(ISP), and yes, they're connected properly with a tag-connect that is confirmed working with AS7), and then I click Burn Bootloader. Only to fail every time, on all three boards.

6

Another clue: Same errors happen when I try to Burn Bootloader on the Arduino Micro or an Arduino Uno. It doesn't see the programmer that shows up in Device Manager!

Also, I replicated the same errors on a Windows 10 laptop. (Was using a 64bit 7 desktop.)

7

Well I don't use Windows, so I'm not sure about this, but I think you need to have libusb installed to use the Atmel usb programmers.

In the IDE examples the ArduinoISP sketch will make your UNO into an ISP programmer.

Your blink program would have to be running on the chip for the IDE reset to work.

8

I've got libusb.a in the Arduino folder, and probably other places as well -- Atmel Studio, etc.

The programmers work with AS, but not the Arduino IDE.

I did load in the ArduinoISP sketch -- same issue, can't see it.

Now I'm trying to swap the original Arduino 32u4 with mine, to see if that magical mystery extended fuse business is the culprit for the programming failure to my boards. As for the Burn Bootloader failure... annoyed and stymied by that one.

9

Okay, I successfully put the 32u4 from my board onto the Arduino Micro. It exhibits the same failure as my board did before, when loading the Blink sketch -- it can't find the board and eventually drops it from the Device Manager.

Since it's on the Arduino board now, I'm satisfied that it's not a hardware issue on my board. I think it has to do with the extended fuse that I can't set to 0xCB. With Atmel Studio, I can try to set it to 0xCB, but when I read it, it comes back up as 0xFB. However, the datasheet doesn't have any functions listed for bits 4&5 of extended fuses. But if they're not used, why are they set on the Arduino???
Is the Arduino IDE somehow able to set mystery fuses that AS is not able to? Bootloader pointer? Or something similar that is not allowing it to program my chip?

10

Atmel studio uses its own usb drivers.

Libusb probably needs to be installed try Google for info. If avrdude can't see your programmer you are not going to get anywhere.

The extended fuse upper four bits are fixed in hardware and cannot be altered. What you see is a difference in how the software is reporting things -- avrdude is wrong, studio is correct. There has been a long term problem with the way avrdude reports unchangeable fuse settings. Just believe the data sheet.

And I am out of ideas, good luck!

11

It certainly looks like the non-Arduino chips are entering bootloader, but not coming back up on a virtual port like the chips off the Arduino do. The mystery to me is why the Arduino chips are not doing the same thing, as I erased them (confirmed) and loaded the same bootloader hex into them fresh.
I guess I could get a ton of cheap Micro ripoffs and take the chips off. The new production style! :slight_smile:

Libusb.a is in the Arduino folder. I'll dig into the reason I can't Burn Bootloader with the IDE later.

Fuses: I have only read fuses with Studio. On the Arduino chips the extended fuses are 0xCB. On the fresh Atmel chips, 0xFB for the same settings, even if I try to write them to 0xCB.
(And don't always trust the datasheet. I've had too many FAEs tell me, "Oh yeah, ignore that, it doesn't work like that." :))

12

Are you saying Studio reads the Arduino 32u4 efuse as 0xcb and your 32u4 chips as 0xfb?

My experiance is that the upper efuse bits cannot be changed by writing a different value to them. Trying to change the efuse upper bits just gets a verification error from avrdude. So if the efuse is the problem how are you going to change the value??

My understanding is that Arduino writes 0xCB to the efuse (per the boards.txt file) to avoid a verification error from avrdude, not to change the upper bits.

13

I know, it's crazy! If I write 0xCB to one of our boards with Studio, it reports 0xFB when I read it.
Both Arduino Micro chips read 0xCB.

Why would boards.txt even have 0xCB as a value? And if the upper bits can't be written to, how can I read it as 0xCB? We have us a bona fide mystery!
As some point I'll keep it as an option to change the boards.txt for my boards, so that avrdude is expecting 0xFB instead of 0xCB.

Anyway, I did have some success with the bootloader burning. It seems that avrdude and Atmel tools (jtagice3, etc.) have had some recent difficulties. Newer avrdude versions are looking for the tool to be using a libusbk driver. I changed that, and was able to burn the bootloader sometimes with ArduinoISP. Still some digging to do there, but a step forward is a good step. At least the IDE sees the tools now.

14

Is the Arduino IDE somehow able to set mystery fuses that AS is not able to? Bootloader pointer? Or something similar that is not allowing it to program my chip?

To my knowledge, non-existing fuses read as logic high. It's either in the datasheet or in some of the avrdude documentation (in the broadest sense, it can be an article on the web).

15

avrdude.conf file for version 6.3 shows how the efuse is used for the 32u4.

...
    memory "efuse"
        size            = 1;
        write           = "1 0 1 0  1 1 0 0  1 0 1 0  0 1 0 0",
                          "x x x x  x x x x  x x x x  i i i i";

        read            = "0 1 0 1  0 0 0 0  0 0 0 0  1 0 0 0",
                          "x x x x  x x x x  o o o o  o o o o";
        min_write_delay = 9000;
        max_write_delay = 9000;
      ;

Which indicates it reads back the fuse value from the chip but does not set the unused ones. I figured this out when I was trying to program a 328pb, and the new fuse bit it has was reading wrong, but I was not able to clear it with avrdude.

Reading the devices efuse was harmonized some time back, but the 32u4 never had an issue.

16

Thanks guys!

I was finally able to burn the bootloader! And program new chips via USB!

The culprit, mostly, was tools. I still can't get the ICE or JTAGICE3 to work with the IDE. Changing drivers got the IDE to see the tool finally, but those tools could never see the target.
And loading the hex file with Studio always had a bug, where the device would look good (hex file read from chip was the same as bootloader hex file), but when you try to upload a sketch, the target would disappear, seemingly unable to come back up on a new, virtual COM like expected.
Arduino as ISP finally worked for me, after some trials. (By the way, as I'm sure you all know, even though the sketch is called ArduinoISP, you don't use the ArduinoISP tool to burn the bootloader. I mean, why would you do that, right? You use the 'Arduino as ISP' tool :))
I also ran into extra problems with Uno -> jumpers -> adapter board -> tag connect cable -> target, where I'm thinking my issue may have been total wire length. Doubtful? Maybe. I tested continuity on the wires. But chopping a tag connect cable and splicing it to the UNO worked. Oh, and uncommenting line 81.

The extended fuses thing... I still don't like the outcome there, but we live with what works, right? The IDE's Burn Bootloader set the fuses on brand new chips to 0xCB. As we say in MN, Okay Then.

sterretje:
To my knowledge, non-existing fuses read as logic high. It's either in the datasheet or in some of the avrdude documentation (in the broadest sense, it can be an article on the web).

Yes, bits 4-7 should be high (as they are with 0xFB), but w/ 0xCB, 4-5 are low.

I do hope this helps someone down the road, but thanks to everyone for the guidance and patience!

17

I see your point now.

efuse for atmega32u4 should probably be 0xFB in the AVR core.

This shows in a few places, is it enough of a bug to add an issue?