A Dead Arduboy + Raspberry Pi + AVRdude + Noob

Yeah I would never chuck it out due to spares and worst case scenario it makes a cool keychain or bag tag :grinning:

Me too :wink:

2 Likes

If it’s a kickstarter version, you could always swap the cases over so you still have the 1 of 10,000. (I assume that’s possible, it looks possible.)

1 Like

A little update now I have a few weekends and the Xmas holidays not too far away I’ve grabbed a cheap EBay pro micro to use as a donor this seems to be the cheapest option compared to buying small amounts of new 32u4’s. I have preflashed it with the hello world example and have serial enabled in the sketch and am tempted to get the custom bootloader from @Mr.Blinky on it…but first things first I need to get a hot air solder station and figure how to use it :joy:

you’d already tried a lot but before going for the hot air desoldering challenge I’d tried one more time to see if the MCU is really dead.

In the other thread. you mentioned something lit up. was it one of the LEDs /OLED or was it a part going up in smoke?

Since you have a voltmeter. When you turn on Arduboy. What voltage do you measure between GND and VCC pads?

The make loud pad closest to the red speaker wire is connected to digital pin 13. With the stock caterina bootloader the breathing LED is output on this pin. you could try connect/solder a LED to it and see if it lights up. (connect cathode of LED to GND connect anode of LED to 1K resistor, connect other end of resistor to the make loud pad closest to the speaker red wire)

trying programming again: DON’T connect the programmer power pin to Arduboy’s VCC pad but switch Arduboy on instead and optionally connect USB cable to Arduboy.

Now that you also have an Arduino pro micro, you can also try that as an ICSP programmer :slight_smile:

1 Like

Possibly any of those the Arduboy was face down at the time but I think it was an LED…

4.01v on battery
4.14v when charging

Tried with and without USB power and still no luck.

I managed to reflash the pro micros bootloader using the USBasp I will look into using it as a programmer however this confirms the USBasp as functional…

So I got a Hot air station as a Xmas gift and swapped the 32u4 with one from a pro micro that I had flashed with an Arduboy game.
The good news is it boots and almost works plus its the first thing I have ever used hot air on in my life.
the bad new is Button A is flakey and TX + RX Led’s are constantly on (with switch) and the Arduboy automatically is on with usb power ( I’m not 100% if this is a bootloader issue or a bridge under the QFN).
Lots of kapton I was being cautious

3 Likes

I don’t think either of these could be caused by having a Pro Micro bootloader on Arduboy hardware.

I removed and reinstalled the 32u4 a second time and all buttons are now working.
With the supplied Pro Micro bootloader I am only able to upload sketches from the Arduino ide,
@crait’s Arduboy manager does the whole uploading process but all it does is reboot the device with no change to the installed sketch. TX and RX remain luminated when the Arduboy is powered.


Just flashed the bootloader with stock Caterina-Leonardo and the LED situation is now resolved.


I seem to recall some discussion a few days ago in one of the other topics custom (bootloader / $12 Arduboy or related topic) mention of something being wired different on a Pro Micro’s LED’s.

The Only thing remaining is to now set my lock bits I am not 100% but shouldnt LB be 0xEF?
lock bits

1 Like

Lock bits should be 0x2F to protect the bootloader. The other fuse settings you show (0xFF 0xD8 0xCB) are correct.

I wrote a sketch that you can use to check the lock bit setting.

1 Like

Thanks Scott.

I finally achieved what I was aiming for it just took a little longer and a lot more £££ all because @bateske forgot to lock the bits :joy:


Edit:
Total cost:

USBasp £3.99
Flux £4.44
Braid £2.59
Solder paste / Liquid solder £7.45
Pro Micro £3.89
SMD Reflow station £34.00 (yes I pick my own gifts ;))
Isopropanol £6.39
Kapton Tape £2.84
Ear buds & other bits n bobs…

Still more rewarding and satisfying than just buying a new one for less.


YES!!! :smile:

7 Likes

Well done! and that for using a hothair station for the first time :+1:

The Micro has the LEDs working in reverse. Pro Micro uses the same configuration as Leonardo. So most likely your Pro Micro was flashed with a Micro bootloader.

Small note on the H(igh) fuses. If you set them to 0xD0 the EEPROM contents will be preserved next time you do a chip erase and burn the bootloader again.

0xEF prevents SPM (Write) in the bootloader section which is what you want. With lockbits set to 0x2F you prevent both SPM and LPM (Read) in the bootloader section.

Thanks - it was a little daunting but as they say you never know till you give it a go.

I’m using AVRDUDESS and set the Lock Bits to 0x2F as per @MLXXXp’s recommendation, It was only after seeing your reply I noticed the sketch is reporting 0xEF in the image I just posted previously.
I just read them back through AVRDUDESS and they are reporting back as 0x2F … I wonder if @bateske will share the Arduboy test sketch that is now used in the factory?


I Am now unable to change from 0x2F to 0xEF


avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e9587
avrdude.exe: reading lock memory:

Reading | ################################################## | 100% 0.00s

avrdude.exe: writing output file "C:\Users\Scott\AppData\Local\Temp\3f2db685-8535-41da-b72e-b691e4cd3702.TMP"

avrdude.exe done.  Thank you.

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 

avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e9587
avrdude.exe: reading input file "0xEF"
avrdude.exe: writing lock (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.06s

avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0xEF:
avrdude.exe: load data lock data from input file 0xEF:
avrdude.exe: input file 0xEF contains 1 bytes
avrdude.exe: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x2f != 0xef
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

Nevermind what I said about 0x2F I was wrong. The protection is the same (SPM only).The only thing is that the high 2 lock bits on ATMEGA32U4 are normaly not implemented and are reserved. Not knowing what they exactly do, i’d say it’s better not to set them to ‘0’. Maybe your lock bits are protected from beeing changed now?

I hope uploading sketches isn’t affected.

Everything seems fully functional, now everything is running fine I think it just needs a “special” Bootloader :stuck_out_tongue:

2 Likes

I don’t think it matters. I’m not sure they even physically exist. The Leonardo (and also the Arduboy) boards.txt file specifies 0x2F to lock and 0x3F to unlock.

leonardo.bootloader.low_fuses=0xff
leonardo.bootloader.high_fuses=0xd8
leonardo.bootloader.extended_fuses=0xcb
leonardo.bootloader.file=caterina/Caterina-Leonardo.hex
leonardo.bootloader.unlock_bits=0x3F
leonardo.bootloader.lock_bits=0x2F

I use this web page for checking fuse settings:

http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega32u4

So I decided to upload a sketch using the programmer thinking “gotta try it once in my life” and
I’ve noticed that if I lock the bootloader using AVRDUDESS at 0x2F and then uploade a sketch using the programmer through the Arduino IDE the bits are then set to 0x3F.

Could this be where the bits are becoming unlocked in the factory?

They remain locked when uploading sketches over USB.

depends on the software they’re using. My best guess is that programmer software was not configure properly. Someone forgot to set the set the correct fuses or check to burn the fuses also

Fuses can’t be set by software (bootloader) only by ICSP programming.

1 Like

In fairness it’d be cheaper to build a second one because the SMD station and USBasp wouldn’t have to be re-bought.

Just to be clear, the lock bits can be set by software but the Leonardo’s Caterina bootloader doesn’t contain code to do it. The commands are disabled by #defines.

Yes they can only be set, not reset (cleared) by software. It’s probably a good thing that they can’t be set from the bootloader by default. If ‘Accidently’ setting BLB01 the Application section would be write protected and you can’t upload new sketches anymore

1 Like