Reading fuse values from custom ATmega32u4 board with avrdude

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm trying to read the fuse bits from a custom-designed, ATmega32u4-based board s part of my continuing quest to get it to behave more like an Arduino, with easy "no buttons pushed" programming.  I'd rather not have to shell out more money to get the board redesigned, so am exhausting the firmware side of things first. 

 

The chip is at factory defaults. RESET is held high, and HWB is grounded. After programming it with dfu-programmer, it shows up as an Arduino Leonardo on OSX. I can get it back into DFU mode by grounding RESET. That's a problem, since this board is supposed to be built into a product. It doesn't exactly make RESET pin accessible if I have to upgrade firmware.

 

Thinking this might have something to do with the fuse bits state, I tried to read them:

ARDUINO_UPLOAD_PORT="$(find /dev/cu.usbmodem* | head -n 1)"
echo $ARDUINO_UPLOAD_PORT  //replies with /dev/cu.usbmodemFD121
avrdude -U lfuse:r:low_fuse_val.hex:h -U hfuse:r:high_fuse_val.hex:h -v -p atmega32u4 -c avr109 -P $ARDUINO_UPLOAD_PORT

...I get the following:

 

avrdude: Version 6.3, compiled on Aug 15 2018 at 11:31:22
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/usr/local/etc/avrdude.conf"
         User configuration file is "/Users/whg2n/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodemFD121
         Using Programmer              : avr109
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : butterfly
         Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding

avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = "?@=??"; type = 
    Software Version = .; Hardware Version = .
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: error: buffered memory access not supported. Maybe it isn't
a butterfly/AVR109 but a AVR910 device?
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

 

I tried the same thing on an Adafrut "Itsy Bitsy" that I bought, and it works just fine. I can not only read the fuse bits, but can also program the board (and reprogram it) directly from Arduino IDE.  The Itsy Bitsy is wired very much the same as my board, except that HWB is pulled high. I've seen other designs, though, where it's grounded, high, or floating, and folks claim to be able to program them. 

 

What gives?  Is this a hardware issue (HWB state), or something else? Why can't I read those d**n fuse bits?

 

One more bit of information that may be relevant:  If I reset the board by changing baud rate:

stty -f "${ARDUINO_UPLOAD_PORT}" 1200

...the board vanishes from the system information screen, and it can't be found by find /dev/cu.usbmodem*.  Same thing happens if I try to program it from Arduino IDE; it sees the board, until the baud rate reset, and then it doesn't. 

 

Again, what gives?

 

ANY and all help appreciated!  

 

<p>~ Athyrio</p>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Athyrio wrote:
is wired very much the same as my board, except

so make it the same!  try lifting the HWB pin off the pcb. 

 

Athyrio wrote:
a custom-designed, ATmega32u4-based board

one usually prototypes these before committing to a pcb.  Arduino Pro-Micros are good for this!

 

To get good answers, you will need to provide the schematic, the pcb layout, and/or a good clear photo of your pcb.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The relevant portion of the schematic is attached. 

 

 

I'm aware that a prototype is a good idea. In this instance the board was designed and created by an electrical engineer subcontractor, so I personally never touched the breadboard version. I'm trying to figure out if the design is usable as-is, or if it needs to be redesigned. I'm not clear from the ATmega documentation whether the grounded HWB is the problem, or if it's something else. 

 

~ W

<p>~ Athyrio</p>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did the contractor include alternate programming such as serial or jtag?

With the HWB pin grounded, upon power up or reset the bootloader code should run, so your bootloader will need some way to "time out" and jump to app code.

IIRC the chips come pre-loaded from the factory with a bootloader (DFU), have they been programmed by some other means before you got it?

Your schematic looks identical to the Arduino Pro-Micro, including the HWB pin is grounded, while the itsy-bitsy has it tied high....

 

Jim

 

Edit: added pro-micro comment

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Fri. Aug 24, 2018 - 01:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No serial or JTAG, I'm afraid. 

 

When received it was in DFU mode, so I was able to program it.  Once programmed, it appears as a Leonardo, and it runs the code on power up, but it can no longer be programmed by dfu-programmer or FLIP.  Transiently grounding RESET with a fine probe returns it to DFU mode, and it can be programmed again. 

 

~ W

<p>~ Athyrio</p>

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, that is good, on the leonardo the fuses are set like this:

leonardo.bootloader.low_fuses=0xff
leonardo.bootloader.high_fuses=0xd8
leonardo.bootloader.extended_fuses=0xcb

 

Compare with yours and see if that helps.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Ok, that is good, on the leonardo the fuses are set like this: leonardo.bootloader.low_fuses=0xff leonardo.bootloader.high_fuses=0xd8 leonardo.bootloader.extended_fuses=0xcb   Compare with yours and see if that helps.   Jim

 

Ah, but that's the problem that I note at the top of this thread... I can't seem to read them! 

 

EDITED: I switched it back into DFU mode by grounding RESET, and tried again to read the fuses, just as in my original post.  I got the same result, AND it kicked it back out of DFU mode.   I'm seriously out of ideas here. 

 

~ W

<p>~ Athyrio</p>

Last Edited: Fri. Aug 24, 2018 - 05:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
so make it the same!  try lifting the HWB pin off the pcb. 

 

I just tried that. I lifted the the pin, and scraped away the trace to the pad for good measure.  No changes in behavior, so I assume that the HWBE fuse is disabled?

 

I'd check it, except that was the point of this entire thread. I can't!

<p>~ Athyrio</p>