bad brownout changes lock bits? unable to re-d/l

Hi there,

I've been using RBBBs (http://moderndevice.com/RBBB_revB.shtml) quite successfully for a little while now, without any problems. I don't have an programmer, so I just develop using an FTDI cable and the diecimila bootloader. (This is pretty close to the vanilla arduino hardware setup.) However, this afternoon, I did something stupid with my hardware which caused a strobing brownout (semi-random cycles of 0 to 2.5V repeating over and over) to the atmega168 chip. Never having had any problems with this before, I decided to take a few seconds to investigate the issue with a meter while the system was on.

I eventually just reverted the hardware change and thought everything was OK again. I took me a little while afterwards to realise that something strange had happened: the atmega168 still booted and ran my software perfectly, with no apparent errors, but I was unable to download anything new to the chip. I use a command-line setup to download using avrdude; it writes fine, but always fails the verification operation.

Confused, I took another RBBB I had lying around and tested that one. No problems, so it's likely not the cable. Then, I swapped the atmega168 chips from one board to the other: the strangely-behaving chip still exhibited the same issue on the other board, while the "mint" chip was fine on the board that initially carried the strangely-behaving chip. Thus, it's not likely to be the board, either.

I'm having no problems downloading (except for verification and the obvious fact that the old code is still there), so I'm guessing the bootloader software is still intact. Like I said above, the software I last downloaded into flash runs just fine and everything seems normal, with the only exception of being unable to download new software.

Does anyone think it's somehow possible the lock bits on my chip were toggled by the brownout, preventing future writes to flash? If so, though avrdude provides options to change the lock/lfuse/hfuse/efuse bits, I believe it is only possible to do so with an ICSP programmer. Is this correct?

Below is an example of the errors I get using avrdude:

abuild.bat: avrdude -C "C:\Program Files\arduino-0012\hardware\tools\avr\etc\avr
dude.conf" -p atmega168 -P COM5 -c stk500v1 -D -b 19200 -U "flash:w:.\obj\Blink.
pde.hex"

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9406
avrdude: reading input file ".\obj\Blink.pde.hex"
avrdude: input file .\obj\Blink.pde.hex auto detected as Intel Hex
avrdude: writing flash (1096 bytes):

Writing | ################################################## | 100% 0.83s

avrdude: 1096 bytes of flash written
avrdude: verifying flash memory against .\obj\Blink.pde.hex:
avrdude: load data flash data from input file .\obj\Blink.pde.hex:
avrdude: input file .\obj\Blink.pde.hex auto detected as Intel Hex
avrdude: input file .\obj\Blink.pde.hex contains 1096 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.84s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0002
         0x5a != 0x5c
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Thanks to anyone for any insight!

yes, flaky power can corrupt the flash. Get an isp programmer and reload the bootloader from the menu and that chip will likely be fine. Unless you fried a pin that is

Cool, thanks a bunch for the quick reply!

Hehe, it's funny how often the "nuke and pave" approach works. I'll likely get a programmer when I import my next batch of mcu's... Or maybe I'll try one of the roll-your-owns, maybe fish out an old PC with a parallel port for this purpose...

Thanks again for the advice!

There's been some recent discussion of brownout detection settings that may help with this issue in the future (e.g. on a new arduino, or if you change the fuse settings yourself).

-j

No prob rap, I eventually got the parallel programmer working, had to ignore the error messages and trust that blinking bootloader pattern meant it worked I popped for a tinyusb kit eventually. A genuine AVR ISP isn't much more than that @ 34 assembled though, the usbtinyisp is a little klunky outside of arduino/avrdude and the atavrisp2 should seamlessly integrate with most avr hardware/software + arduino.

if you have an official decimilia (or can solder real tiny) then search for ser-jtag for a possible diy also. Here
's a good link: http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html

@kg4wsv: as I perused the documentation for the lock bits, I couldn't help but wonder how the arduino atmega168s came configured in the brownout detection department. Since my atmega was already "done in," however, I figured the point was a bit moot to me at that juncture. But it's certainly cool if people are thinking about this problem in the grand scheme of things..! I'll be curious to follow that issue. I think it's great how accessible the Arduino platform is to the general public, and this would be yet one more step.

@dcb: Haha, the JTAG-over-FTDI hack is pretty darn nifty..! I didn't know the FTDI chip provided that level of signal manipulation. Thanks for the link! Come to think of it, that makes me think of other uses for that FTDI cable... In fact, I've not thought the details over, but it sounds as though one might be able to jerry-rig something to use an FTDI cable directly and build an ICSP adapter for it. (From a cursory look at the article, it seems like they're essentially hijacking the FTDI on the arduino to do just that.) That does look more complex than a basic parallel port programmer, though, so I'll probably try that it out first, see how things go... pop my unresponsive atmega168 into my old NG board to program it. (RBBBs don't have an ICSP header.) If I do try to use the FTDI cable directly (or solder the headers onto my NG) I'll be sure to report any findings.

Failing all that I might just do like you and spring for a ladyada kit. No shortage of snowy afternoons here, a good excuse to stay warm by the soldering iron.

Thanks to both the information!

Ah, I don't know about cutting open the ftdi cable. sounds extra challenging. You can get to all the isp pins on your rbbb, they just are not in a nice 2x3 cluster cluster. But they are in two groups of three 17,18,19 (d9,d10,d11) and +5,gnd,reset.

And here's the "standard" 6 pin pinout:

P.S. Don't forget about programmer2, use an arduino applett as a programmer: Arduino Playground - Programmer2 , never got very far with it myself but always thought it was "cool".