Butterfly bootloader stopped working

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

I've been playing around with a butterfly for the past few days, trying to get to grips with timer interrupts by generating clicks on the piezo speaker, and my programs seemed to be doing more or less what I expected, when suddenly I started getting verify errors whenever I tried to send a new program.

The error I get is always at offset 0, where it is reading back 0100 instead of what was expected. I used AVRProg to try to read the flash area back and what it read was always 000102030405060708 etc.

I think the erase is failing too since it seems that the program I last sent is actually still there (it's clicking the piezo once per second).

I tried removing the battery but no luck. It seems like either I changed some setting on the chip that caused the bootloader to malfunction, or else part of the bootloader got reprogrammed.

Two questions:

1. Is it possible to accidentally reprogram the bootloader itself via a badly-behaved program?
2. Are there any settings that I could have accidentally changed (that would survive a battery removal) that would cause the bootloader to malfunction)
3. Is there a way to fix it?

Ok, so I can't count.

Thanks in advance for any assistance/sympathy that you can offer.

Richard

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

There is a very extensive recent thread on this--search it out.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I did search - but have not yet found anything that sounds related. It's harder to search when I don't know what I'm looking for. DO you have a reference to the thread in question?

Thanks

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

Of course, as soon as I say I can't find the thread I find it....

Sounds like a design flaw in the bootloader allows a corrupted datastream (possibly caused by a low voltage or hitting the joystick while progamming) to set some lock bits which it cannot then unset. The only way to unset them is via a more expensive programmer using the ISP or JTAG interface.

I have a love/hate relationship with the butterfly right now - it promises so much but doesn't quite deliver...

Would a swppi ISP programmer as referenced at http://bluebat.dnsalias.org/howt... be a way to fix this without further outlay?

Richard

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

For reference, if anyone else hits this issue, it IS recoverable via an ISP programmer based on a parallel cable and 4 resistors. I'm back in business (and now now much more about lock bits that I ever wanted to)

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

Did you measure the voltage on your battery? I'm curious if this might becausing the problem for some folks.

Smiley

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

I'am having a similar problem, all I get when reading flash and eeprom is 0001020304050607 ... FF. I'am trying to reverse engineer a very nice battery charger for RC-batteries. It has a ATmega16 in it. I would love to add support for SD-card so I could select from a list of batteries instead of doing the actual settings every time i'am charging another battery.

Which Fuse is it that cause this? not SPIEN right? Since I can communicate.

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

Quote:
I'am having a similar problem

??? The problem stated (5 years ago) was about the Butterfly (ATmega169) bootloader.

I think your ATmega16 is probably protected, so you're out of luck unless you hire a crook. Read the datasheet about the fuse settings for more information.

Chuck Baird

"I wish I were dumber so I could be more certain about my opinions. It looks fun." -- Scott Adams

http://www.cbaird.org

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

Quote:

I get when reading flash and eeprom is 0001020304050607 ... FF.

That's exactly what you get when the lock bits are set - 'fraid you are out of luck - some outfits in the Far East will offer to break the lock for $500 but that moves you from the realms of "tinkerer" to downright "thief"

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

Well as long as I keep the code to myself and make no gain of it, i would still consider it tinkering :)
But it would'nt be any fun.

I simply have to connect to the buttons and LCD instead to interface the charger using another AVR.

But it such a shame, just adding a SD-card to the SPI-pins and reprogram the CPU would have made a great charger into a super-duper-mega-great charger.
GPL for the win! :)

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

I guess all you can do is observe how the current design operates then try to duplicate that behaviour in a completely new implementation. If it's under 16K of code you *may* be able to completely mimmick it's behaviour. You can certainly duplicate it's output behaviour but what you don't know is how its processing any inputs it's given.