Berndiboy - Homemade Arduboy

A fresh one will have the default factory configuration. So it doesn’t behave the same as one on a ProMicro board.

A fuse is a default configuration bit. when the CLKDIV8 fuse is programmed the clock is divided by 8 on power up. So with a 16MHz clock the atmega32u4 will only run at 2MHz

Have you successfully used it with another MCU? Did you select the Arduino as ISP as programmer (ArduinoISP is wrong) ?

Have you successfully used it with another MCU? Did you select the Arduino as ISP as programmer (ArduinoISP is wrong) ?

Yes i have used it with a fresh Atmega1284p before already. And yes i have selected Arduino as ISP

Somehow i am even too stupid to quote correctly :smiley: sorry …

As a life lesson for me on the old Atmega uC’s batch you can short the outputs how long you want to VCC or GND does not pop ( do not draw more than 200mA on the power pins ), never drive them more than 0.5-0.7V above VCC or below GND, this is the reason that I search the old batch of Atmega, the new ones with U suffix ( Microchip ones ) are made on another process and I do not experiment to much with them, they pop more frequently they are more sensitive.
The old batch was so reliable that I found them inside the Xray guns in medical applications ( Atmega128 )

How do you know the uC has entered programming mode? The programmer may be sending the “Programming Enable” command without reading and checking the 0x53 that is echoed back during the third sent byte. The programmer may just go on to doing the “Read Signature Byte” commands and using them as an indication that program mode has been entered.

If the programmer actually is looking for the 0x53 reply, and not proceeding without it, then there can’t be any problems with power or any of the signals, or the programmer wouldn’t have received the 0x53 and wouldn’t move on to reading the signature without it.

I would hope that any programmer worth its salt would realise this possibility and (at least initially) run below this speed.

Without any other components on the board, either 3.3V or 5V should be fine. 5V may be a better choice.

In theory you are right.

In practice there can be issues in the power side, a short somewhere, or the programmer SPI frequency to be to high, need to be around 500Khz for a uC clock of 2Mhz I believe. :thinking: normally F uC/2 but if the F is a little bit under 2Mhz there will be issues in the communication with uC, so best is F uC/4 for SPI frequency.

Did you upload the default ArduinoISP example or made changes before uploading it?

The default sketch is configured to handle devices with as low as a 1MHz clock. But you could try lowering the SPI clock by 10 times by removing a zero in the line:

#define SPI_CLOCK 		(1000000/6)

Are you sure you wired up the Uno programming wires correctly?

removed a zero and double checked the wiring, no difference :frowning:

avrdude: Version 6.3-20190619
     Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
     Copyright (c) 2007-2014 Joerg Wunsch

     System wide configuration file is "C:\Clean\arduino-1.8.12\hardware\tools\avr/etc/avrdude.conf"

     Using Port                    : COM6
     Using Programmer              : stk500v1
     Overriding Baud Rate          : 19200
     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 : STK500
     Description     : Atmel STK500 Version 1.x firmware
     Hardware Version: 2
     Firmware Version: 1.18
     Topcard         : Unknown
     Vtarget         : 0.0 V
     Varef           : 0.0 V
     Oscillator      : Off
     SCK period      : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.04s

avrdude: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

Error while burning bootloader.

Can you tell us more about this “cheap” oscilloscope that you have? Even if it’s not fast enough to look at the 16MHz crystal frequency, it may be able to look at the programming signals. It could verify:

  • That the 32U4 is seeing the programmer toggle the reset line.
  • If a programming clock signal is being received on the 32U4 SCK pin.
  • If a proper signal is being received on the PDI (MOSI) pin.
  • If the 32U4 is sending a response on the PDO (MISO) pin.

It is a DSO Nano:

longshot: Try copying the AVRdude command line from the IDE log and paste it into a command windows (CMD) and then append a space and -B 100

Not sure if it’s been said already but check if there is a short between the clock pins or GND at the atmega.
(missed one ofg your messages where you mentioned you check for shorts)

That scope only has a 200KHz bandwidth, so it couldn’t check the crystal, but is would be useful for checking the programming signals with the programmer set for a slow speed. It could confirm that all the output signals are getting where they should and also that the power supply is clean.

Brings me back to the fact that i would not know how to use and how to read it… So i assume this is out as an option.
Normally i am not givin up fast but when you can’t explain why it does not work you are just lost. And beside that this good feeling when something works out is just not there… Feeling kind of sad at the moment :frowning: Working on it now since weeks without a single success experience can bring one down.

1 Like

For the simple testing that you would need it for, it shouldn’t be hard to set up and learn how to use. It would be good for you to learn how to use it anyway, rather than having it go to waste.

Since you’re using a UNO as your programmer, you could write a sketch for it that just toggled each output (Reset, SCK and MOSI) individually and then use the oscilloscope to see if the signals are getting to the 32U4 pins properly, without affecting the others. Once that was working, you could use the scope with the programmer code running to see if the actual programming signals look OK. You could also use the scope to look at the power supply to the 32U4 for noise or dips that could cause problems.

If after all this, everything looks OK, but the 32U4 isn’t responding to programming, the most likely cause would be that the crystal generated clock isn’t working (or the chip is bad).

I can imagine your dissapointment (and frustration) for not being able to find out what’s wrong. Give it a break for a day or few so you can look at it again with a fresh state of mind. The positive of your situation is that you’re learning a lot.

You’ve said you’ve used the Uno as an ISP programmer before successfully. But you should confirm your Uno as ISP is functioning properly in the current setup. Try hooking it to a Pro Micro or one of your modded Arduboys expansion connector and see if ISP-ing with it works. Open a command line promt and copy and paste the following line (using the path from your log above):

C:\Clean\arduino-1.8.12\hardware\tools\avr/bin/avrdude -CC:\Clean\arduino-1.8.12\hardware\tools\avr/etc/avrdude.conf -v -patmega32u4 -cstk500v1 -PCOM3 -b19200 -Ulfuse:r:-:h -B 100

When successful the above line reads out theID and fuse settings and you can rule out a programmer issue (unless you wire up your Berndiboy incorrectly for ISP)

To test a clock issue, you could use one of the Unos timers and configure it so it toggles an GPIO pin and feed that into the atmega32u4 as a clock at pin 17 XTAL1

To test the Unos gpio pin toggling. You could set the timer to a low frequency first and test it’s output using a piezo speaker.

When you’re able to read the fuses with this setup and the above command . try writing the low fuse to 0xFF using:

C:\Clean\arduino-1.8.12\hardware\tools\avr/bin/avrdude -CC:\Clean\arduino-1.8.12\hardware\tools\avr/etc/avrdude.conf -v -patmega32u4 -cstk500v1 -PCOM3 -b19200 -Ulfuse:w:0xFF:m  -B 100

This will not only unprogram the CLKDIV8 fuse but also set a different clock configuration with a 65ms startup delay which will help stabelize your ceramic resonator

2 Likes

Don’t give up!
But I would say you’ve taken a very difficult approach… :grimacing:
Even experienced electronic engineers like to build up circuits bit by bit, using prototyping (like breadboards, etc.). This debugs the hardware and perhaps more importantly, checks our own understanding.

PS- The Arduboy started life with @bateske grabbing ‘blocks’ of existing circuits and sticking them together. It’s a great approach to starting a project. https://www.youtube.com/watch?v=kMlphQcv9zQ

2 Likes

Hi together,

thanks for the kind words. Gives back some energy. I also took one day off to get the head free.

I will try to do the extended testing with test sketch on the pins and also try your approach @Mr.Blinky

@acedent: Thanks. But i can make you some pictures of things i have already built in the past and you will realize that in theorie i should be able to “hit the next step”. My only problem is that i also just use existing examples and put them together but without the complete knowledge around electronics… So when it works - perfect. When it does not work and it is not a short or anything else simple then i am lost… But i was lost with creating PCBs 2 months ago and never made an own schematic, so to learn some basics in signal testing etc seems to be the next necessary step in the journey :exploding_head:

I will continue today and share the results.

Thanks again to all for the help and nice words!!

1 Like

@mameise, What is the make and model of the multimeter you have? If it is capable of measuring frequency (and you don’t want to try to use your oscilloscope), it could be useful. @Mr.Blinky’s idea of using a piezo speaker is good, but measuring frequency using a meter may be more convenient for this.

Did you select the leonardo as your board before trying to burn the bootloader. The ide has to know that, trying to burn another bootloader could cause this message!

Sorry, was busy last days and could not really continue. I highly doubt that i have such a super multimeter :slight_smile: But i will look up the model (it is from Voltkraft, that i know)and provide you the model. Thanks

1 Like

Have you had any luck yet? I think the below may be of some help.

last weekend I burned the factory default fuse settings to an atmega32u4 of a Pro Micro for test purposes and after the fuses were changed. I was unable to use any of my ISP programmers.

The reason why is that with the default fuse settings the 32u4 requires an external clock supplied to the XTAL1 pin.

To supply an external clock I took another Pro Micro (got a bunch of these :grin: ) and programmed it with the below sketch to output an 8MHz clock on pin 9.

I soldered a wire to the capacitor connected to XTAL1 on the non programmable Pro Micro and connected it to Pin 9 of the Pro micro that generates the 8MHz (also connected GND and Vcc ofcourse)

With this setup I was able to program the Pro Micro again. After flashing the correct fuse settings. It can be programmed normally without the 8MHz clock connected to XTAL1.

8MHz clock generator sketch
constexpr uint8_t OCR1A_PIN = 9;   // Leonardo / (Pro)Micro clock output pin
constexpr uint8_t OCR1A_8MHZ  = 0; // asuming board uses 16MHz clock
constexpr uint8_t OCR1A_4MHZ  = 1; 
constexpr uint8_t OCR1A_2MHZ  = 3; 
constexpr uint8_t OCR1A_1MHZ  = 7; 

void setup()
{
  pinMode(OCR1A_PIN, OUTPUT); // configure clock output pin
  TCCR1A = ( (1 << COM1A0));
  TCCR1B = ((1 << WGM12) | (1 << CS10));
  TIMSK1 = 0;               
  OCR1A = OCR1A_8MHZ;
}

void loop() 
{
}
XTAL1 access point on Pro Micro (for general reference)

afbeelding

1 Like