0x940c in AVRProg error message - bootloader confusion?

Go To Last Post
192 posts / 0 new

Pages

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

Quote:
The first Butterfly bit the dust when I tried downloading the original code (just to see if I can download anything). I had never used AVRProg before so I didn't know what behavior to expect or when to release the button etc.

I did the same thing and the problem occurred but the butterfly will turn on to pushing "up" on the joystick. On early Olimex JTAGs they had a problem in the boot loader and the same(type) of message appeared http://www.olimex.com/dev/avr-jt.... This must mean that the problem is the bootlaoder and Atmel should attend to it. I'm also a customer of Smileys but am perfectly happy with my butterfly because I have an ISP. I would advise all to have some kind of backup programer.


My AVR Site

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

After about 9-10 months, I finally decided to experiment with my butterfly about an hour ago, rather than just used it as an easily accessible practical demonstration of my hobby to our family friends.

Fist off, solder headers to the pads - check. Second: attach butterfly to "SPARE RS-232" ON STK500 - check. Open terminal program and set mode to "download name" - check. No dice.

Took me five minutes to remember that the butterfly uses funky level shifting circuitry onboard which means it won't work if the signal is already converted via the '500's MAX232. I then changed the connections to interface directly with the serial port and it all worked fine.

Just before I loaded in Martin Thomas's GCC port of the original bufferfly code (which is almost poetic in it's sheer greatness). Works great - and no 0x9C error! :D All I need to figure out now is what to do with the thing...

I had a poke around on Atmel's website for the bootloader code - and all I found is the HEX. I assume Atmel are protecting their protocol?
- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Dean oh Dean, Exposer of the Impatience of Youth!

Go back to the Butterfly page at Atmel. Instead of just diving for the downloads at the bottom, read the text above them:

Quote:
The bootloader source code is available as application note AVR109.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

I saw that, but all it was was a description of the bootloader, with no code that I could see. I went back to the website and (doh) realised that the code is in a zip file which accompanies the PDF.

In any case, I think it would be interesting to make an ISP programmer out of an AVRButterfly. I doubt you could get it to work with the AVRISP protocol (if you did it would be outdated soon enough anyway) but with AVRProg it should be fine. Since the butterfly's got an onboard screen, joystick, dataflash and whatnot, you could even make it able to store programs and program AVRs in-field...

This calls for some investigation.
- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:
This calls for some investigation.

Forward, Dean, and onward! (Us cowards will await in the rear until the enemy is defeated...) 8)

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

abcminiuser wrote:
In any case, I think it would be interesting to make an ISP programmer out of an AVRButterfly. I doubt you could get it to work with the AVRISP protocol (if you did it would be outdated soon enough anyway) but with AVRProg it should be fine. Since the butterfly's got an onboard screen, joystick, dataflash and whatnot, you could even make it able to store programs and program AVRs in-field...

This calls for some investigation.
- Dean :twisted:

Dean,

First off look at the bootloader on Martin Thomas website:http://www.siwawi.arubi.uni-kl.d...

Second, your project idea is excellent and the Butterfly could do it. There are plenty of resources for AVR ISP programming both here on Freaks and through Googling. While it would be a large project, it would mostly entail re-engineering existing code AND it would be a contribution to the AVR tribe.

Good Luck,
Smiley

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

Im that newbie with this same problem...

I have an Atmel Butterfly.
I have successfully loaded half a dozen different programs into it.
I am now not able to upload any new programs to it with AVRprog.

I get to "Verifying" in AVrprog and get a popup that says:
Address: 0x0000, Expcted: 0x940c, Received: 0x0100

Then I get a verify failed.

I have seen references to replacing the bootloader with avrdude and
a connector from the pc parallel port to the jtag port.

Any ideas on how to salvage my butterfly? :(

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

kl7r, if you read any of this thread at all you would have realised that the way to fix your butterfly is to use an ISP programmer such as a STK500 or a ATAVRISP.

Smokey: Working on it now. Took damn forever to get the screen and joystick working correctly, but i'm now happy with it. I'm trying to get the blasted serial to function next - looks like i'll be having another look-see in your book. I was browsing the schematics of the butterfly - is it really running of the 32.768KHz crystal? That's what's connected to the occilator pins, as far as I can tell...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Actually I did read the thread. Try to be civil.

That is the reason that I had the following line in my post:

"I have seen references to replacing the bootloader with avrdude and
a connector from the pc parallel port to the jtag port."

That should have read "ISP port".

I got a copy of avrdude and wired up an isp port programmer cable
to go to the ISP port but so far no joy. avrdude doesnt see my butterfly
for some reason. A scope shows data coming out of lpt1 so I know
my drivers are working and I doublechecked my isp cable but no luck so far.

I used the information on http://bluebat.dnsalias.org/howt...
and the windows/cygwin version of avrdude that comes with WinAVR

Do I have to do something special to get the butterfly into ISP program
mode?

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

Dean: The BF is running on internal R/C with the factory default fuse-settings. In the example application the "Watch-XTAL" is used to drive the RTC in async-mode and to calibrate the internal R/C during startup. I recommend that you copy the initilisation functions from the sample-application into your code if you are going to interface the BF to your PC via UART.

Martin Thomas

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

Hi,

I've bought my first butterfly this week, and now I've also the programming problem. First I downloaded a file and wrote it to the butterfly successfully. I used the AVR studio to change the code, build a .hex-file and wrote it to the bf, successfully too. But after the next change & build I couldn't write any more.

I use a serial connection directly to the butterfly, I don't have this stk500. I use avrprog, but the verify fails.

One confusing thing is that the avrprog shows me "ATmega16 BOOT" as device. On the Advanced window there are none of the lock bits set (Mode 1, BLBo Mode 1 and BLB1 Mode 1), also all five fuse bits are unset. The device signature is shown as "1E 94 05", the target board "AVRBOOT", target SW ref 1.4. Is this ok?

I tried to use AVRdude (for windows), but the software won't recognize my butterfly or I use the wrong options:
avrdude.exe -p m169 -c butterfly -P com2 -U flash:w:"AVR_Butterfly_rev06.hex":a -U flash:r:"AVR_Butterfly_rev06.hex":a -U flash:v:"AVR_Butterfly_rev06.hex":a
(I just removed the path of the .hex-file and the exe).
-------------------------------------------------------
Output:
avrdude.exe: Version 4.4.0cvs
Copyright (c) 2000-2004 Brian Dean, http://www.bdmicro.com/

System wide configuration file is "C:\Programme\Atmel\WinAVR\bin\avrdude.conf"

Using Port : com2
Using Programmer : butterfly
AVR Part : ATMEGA169
Chip Erase delay : 9000 us
PAGEL : P00
BS2 : P00
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Memory Detail :

Page Polled
Memory Type Paged Size Size #Pages MinW MaxW ReadBack
----------- ------ ------ ---- ------ ----- ----- ---------
eeprom no 512 0 0 9000 9000 0xff 0xff
flash yes 16384 128 128 4500 4500 0xff 0xff
lfuse no 1 0 0 2000 2000 0x00 0x00
hfuse no 1 0 0 2000 2000 0x00 0x00
efuse no 1 0 0 0 0 0x00 0x00
lock no 1 0 0 2000 2000 0x00 0x00
signature no 3 0 0 0 0 0x00 0x00
calibration no 1 0 0 0 0 0x00 0x00

Programmer Type : avr910
Description : Atmel Butterfly Development Board

Found programmer: Id = "???????"; type = ?
Software Version = ?.?; No Hardware Version given.
avrdude.exe: error: buffered memory access not supported. Maybe it isn't
a butterfly but a AVR910 device?
-------------------------------------------------------

The battery seems also be ok, I measured 3V.

Any suggestions?

Regards, derniwi.

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

I decided to check out a couple of things before responding, so I hooked up one of my Butterfies that resides in a relay control device and AVRProg wouldn't talk to it. So I hooked up another Butterfly that resides in an ADC device and AVRProg wouldn't talk to it. I fiddled and fumbled and rebooted and did all kinds of stuff only to find that my RS232 cable had gone bad. I had tried a USB to RS232 cable which didn't work either but upon further investigation I learned that AVRProg only scans COM1 to COM4 and my USB/RS232 was on COM8. Found another RS232 cable and was back in business.

The point I'm trying to make is that anything could be wrong. One potential problem is the coin battery which drains very fast using the RS232 and a voltage indication of 3V is nearly meaningless since the battery could be near empty and read 3V with no load and drop like a stone when you put a load on it. I use 2 AA batteries. Next test you connections, even resolder them if you aren't sure. Another problem I've encountered is having the port already open, for instance in a terminal program then trying to open it with AVRProg which won't work unless the other software closes the port first. Usually after about 15 minutes of hacking, I revive my Butterfly.

Good Luck,
Smiley

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

Smiley!

Although the point that "anything can go wrong" is absolutely valid in a general sense, I doubt that this is the case with the problem at hand. At least for me the serial communication between the PC and the Butterfly was OK, as I could change my name in the BF app. It was the bootloader programming that went awry. The weak battery theory does not hold in my case either, as I powered my BF from a wall-wart (1500 mA @ 3V should leave ample head-room, nest-ce-pas?).

It's been a while, quite a while, since I did any tests. I'm not dependent on the bootloader as I can program the BF with my STK500. I have in fact not had my BF out for several months, but if I can help in any way then please tell! It's really a bummer that such a good entry point into the AVR world is tripped by something like this.

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Actually I don't think the last problem is the infamous 0x940C issue but as I said could be anything... maybe the bootloader crapped out, who knows.

Thanks for volunteering, but this weirdness is hard to replicate. Maybe since you are in Sweden you could drive over to Trondheim and yell at somebody?

Smiley

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

I tried everything I could think of 5 times to get this butterfly
to reprogram.

I built an SP12 cable and an SWPPI cable
Tried them both a dozen different ways with avrdude.

avrdude cant see the device to reprogram it.
avrprog can see it enough via the serial port to try to write
code to it but I get the 0x940c after the verify.

The last program I wrote to it is still there and functions
so the butterfly works it just doesnt want to listen.

I am a bit frustrated.

Is there a special state that the butterfly must be in in order
to receive new code?

I tried shorting the two pins.
I tried removing and reapplying power.
I tried the above two with the button pushed in.
I tried the above with pressing the button after the power reset.

Unless someone is willing to try to write a new bootloader
to it, I am going to have to shelve the project until if/when I buy
another butterfly.

Anyone know how to wire up the display
to use as output for a 16F84?

Does atmel give out butterfly samples?

:?

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

KL7R,

I'm not familiar with that cable - I assume it's just a serial cable? What you need is an ISP programmer - i'm actually writing code as we speak to turn a Butterfly into an ISP programmer (which will eventually be able to store files and program AVR's without a computer) and i'm about 60% done coding the AVAVRISP equivelence code. When it's done, you can purchase another butterfly, load this onto it, fix your existing one and then either keep the second butterfly as a equivelent ATAVRISP or reprogram it to do your bidding.

The bootloader is actually extreamly simple - I downloaded it expecting complex C code, and was plesantly surprised. You (or I) could always remove the lockbit functionality to prevent the problem from occuring but you would still need an ISP programmer to load in the new bootloader.

Yes, Atmel gives out free butterflys (and other gear), but only in special occasions - like their seminars - or under special circumstances.
- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

They both come off the parallel port of the PC.
Different pins of the parallel port act like mosi,miso,rst, and sck

Check out the avrdude.conf file and you will see a config in there for the sb12
cable

Here are the links that I used to build the cables:
http://bluebat.dnsalias.org/howt...
http://www.xs4all.nl/~sbolt/e-sp...

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

Hi,

I've just tried to reprogram my butterfly while connected to an external power source, also it is still not possible.

What is about avrprog and butterfly? Is "ATmega16 BOOT" ok for a butterfly? I expected something like "ATmega169" or "ATmega169 BOOT" as device since I can find this text in the avrprog.exe.

Regards, derniwi.

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

Hi kl7r :)

I went through this a while back..here is my sad tale
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=33220&start=0&postdays=0&postorder=asc&highlight=sick

Quote:
Anyone know how to wire up the display
to use as output for a 16F84?

So, you program PICs too huh? I use PIC and AVR...but I now prefer AVR.

I was looking at your web page (found link on QRZ.com when I looked up your call)
and see that you like the rockmite...they are so cool..my cousin has 2 of them.
(too bad they used a PIC on them and not an AVR though)
Also saw your cute little yaezu portable radio...way cool!
I have an ICOM 703 that I use for just listening right now...but when/if I get my
license I will be on the air with it...I know morse already (I use morse to communicate
with my controller projects)

ere has a low-cost programmer that should be able to get your butterfly back in shape.
[url]http://www.ere.co.th/(xmbdoa55oehns2uamrouerj2)/default.aspx?RedirectPage=Products&RedirectPage1=ProductsDetail&ProductID=55[/url]
be sure to get one of the 10 to 6 pin adapters if you get one though..so it will
plug into your butterfly easily.

Good luck with the butterfly :)

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

kl7r wrote:
Unless someone is willing to try to write a new bootloader to it, I am going to have to shelve the project until if/when I buy another butterfly.

When you get an ISP programmer use the bootloader from: http://www.siwawi.arubi.uni-kl.d...
This is the WinAVR port of the OLD Butterfly bootloader which I believe doesn't allow setting the lock bits so it is less prone to the 0x940C bug.

Good Luck,
Smiley

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

AVRBOOT16 is indeed correct for the butterfly. In the bootloader code (I believe it was there - i've been reading a lot of butterfly-related material in the past week) there are comments that say that because AVRProg doesn't support the MEGA169, you use BOOT16 instead because the protocol used is identical.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Serious Joy here in butterfly-land.

With help from dl8dtl over on the avrgcc forum I was able to find the problem with my sp12 cable
by looping mosi and miso back to each other with a shorting wire in my sp12 isp header.
The problem turned out to be superglue in the header so the pins were not making good contact.
When the loopback worked, I then tried burning on the code for the
app 06/bootloader 03 and then I was back in business !!

Smiley:
I did try the boot loader / gcc code you mentioned before my butterfly stopped listening.
I will do as you suggest and run that bootloader.

Thanks everyone for all the help.
Happy Holidays from Alaska :)

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

I did some experimenting with the different bootloaders.

bf_boot_20050503 works reliably in all cases

bf_boot_rev3 fails consistently now.
if I try to reload bf_boot_2003 with bf_2003 -it fails
when I try to load it. it asks if I want to write the boot area
and if I want to write past the truncation limit.
answering yes gets the 0x940c error
answering no gets a hang and crash in avrprog

I seem to recall being able to reload the bf_boot_rev3 with app code
before this problem started happening....

If I try to load application programs - they seem to work ok with rev3

Im kinda thinking that the problem started happening with me originally
when I wrote the GCC bootloader... I think something might have
gotten set with the GCC bootloader that causes the rev3 bootloader
to trucate. I do recall experimenting with GCC LCD I/O and with
the GCC bootloader before I had the original 0x940c problem.

You might have the fellow that is looking into this problem experiement
with the two bootloaders and see if there is a trucation problem or
something...

I am going to stick with bf_boot_20050503 and my application code.

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

Hi kl7r,

so you just use a SP12 cable and you are able to reprogram you butterfly with this? That's all the magic in your case?

Regards, derniwi.

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

Hi,

I've got an AVR910 compatible programmer now, and I'm on the road again. Only one thing happens, my butterfly won't sleep now... but I'm looking for this.

derniwi.

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

derniwi wrote:
Only one thing happens, my butterfly won't sleep now... but I'm looking for this.

Try Chamomille tea and if that doesn't work Melatonin might. As a last resort put it in a jar with a cotton ball soaked in ether and seal it tight.

Smiley

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

Hi Smiley,

I used a little hammer and knocked it out...
;-)

derniwi.

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

Hi all,
I just re-read this whole thread. I was thinking that we learned a lot along the way and that it would be nice to try to summarize. Unless I missed something it looks like we did not reach a solid conclusion. But as it stands someone coming in cold with a dead Butterfly may be more overwhelmed by the discussion than the problem with their Butterfly. So I have two ideas.

1) I want to take a stab at a preliminary conclusion. If all of the verified 0x904c problems follow the same pattern then at least we may be able to help people prevent the problem and simplify troubleshooting.

2) I want to bounce around some ideas to prevent it.

1) Let me put up a strawperson. I propose (not that it is an original idea) that the problem has only one cause and it is a voltage drop during programming.

From talking to Smiley, re-reading this tread and personal experience it seems that most of the verified 0x904c errors come from people programming while powered by the coin cell. It also looks like most of the remaining problems came after people had been working with their Butterfly for some time. So maybe their external batteries were getting weak. I know that JohanEkdahl had the error while using a wall wart.

JohanEkdahl could you confirm that you had a verified 0x904c error and that you never programmed with a battery? Even if he programmed only with a wall wart could we assume that he had some kind of power dropout?

This may seem like not much of a conclusion but if the collective experience of the group is that the vast majority of problems follow this pattern maybe we can prevent at least a few people from wasting dozens of hours like many of us have.

2) On to the fun and creative part, namely preventive solutions or at least a warning that it is time to change your batteries. Smiley is certainly right when he says that you can’t just watch voltage because the coin cell can have a high voltage until it is almost dead and long after it is able to supply enough current to maintain that voltage under load and I’m still thinking there may be a solution.

What about a watchdog circuit? The Butterfly has a built in voltmeter. What if we suggest to people that they add a line at the beginning of their code that blinks an LED and measures the voltage drop across the LED’s current limiting resistor at the same time. It displays that number and you store it in the code. Once the measured value drops to say 80% of that value the code displays a warning (by say blinking the LED three times) that it is time to change you batteries.

In fact I’m not sure that this idea will work since the voltmeter is scaled to the input voltage and the whole thing is too recursive for my tired brain, so I throw it out to all of you folks. Maybe we don’t use the voltmeter. What about watchdog circuits, RC circuits or other features that are already available on the Butterfly. Any ideas?

George
-------------------------------------
FlutterBot.com

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

I installed an older revision of the bootloader and don't have the problem anymore...even with the battery.


My AVR Site

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

LCD*AVR4me wrote:
I installed an older revision of the bootloader and don't have the problem anymore...even with the battery.

That is a good point. Certainly anyone that has a programmer should be told about this option. Which version of the bootloader worked for you?

George Albercook
www.FlutterBot.com

George
-------------------------------------
FlutterBot.com

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

I had my original, and rather battered, Butterfly lock up on me a week or two ago with the error. This was after a substantial (read: >50) programs of the flash memory, each time powered by the coin battery. A check showed the battery over 2.8V at the time of spontaneous locking.

I had a brand-new Butterfly lock straight out of the box on it's first program. This was using it's included brand new coin cell. Since then i've switched to JTAG programming and all is proverbially well.

Downgrading the bootloader works as a protection because earlier versions did not have the fuse/lock setting feature and so a malfunction of the bootloader (perhaps due to undervoltage) couldn't cause a spontaneous locking of the memory.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Do we know if Atmel has fixed the problem in the next batch of Butterflys?

George Albercook
www.FlutterBot.com

George
-------------------------------------
FlutterBot.com

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

Quote:
I know that JohanEkdahl had the error while using a wall wart.

I had the problem and I never ever programmed with the battery. I made a regulated
power supply from a wall wart and a 317T regulator...the voltage set at 3.3v

There was no power failure when the error occured and the capacitor in the wart
would have carried the butterfly for a fraction of a second even if there had been
a very short power drop in the ac.

I wondered if it was possible that the 317T could have been suffering from some kind of dropouts...but I ran a test program that would fail if there was
a power drop and ran it for a week on the butterfly...it never lost power even for
a fraction of a second.
(the test program required pressing the joy button to start so if reset it would not be blinking the LEDs)

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

I used the GCC port of the bootloader from:
http://www.siwawi.arubi.uni-kl.d... with the time stamp of 20040127


My AVR Site

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

As always nice work Gwen! Sounds like the theory that voltage dorp is the sole cause is pretty much dead.

Next step. Has anyone had a failure with Martin THOMAS's GCC port?

George Albercook
www.FlutterBot.com

George
-------------------------------------
FlutterBot.com

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

Quote:

JohanEkdahl could you confirm that you had a verified 0x904c error and that you never programmed with a battery?

I can confirm never having programmed the AVR with a battery. It has been tucked away for a long time. I can not at present confirm with 100% certainty that I had a verified 0x940C error as my synapse-based bio-memory (brain) has thrashed that page to the dead-page-pool months ago and I dont have the BF out handy for the time being. If I have said in any posting that I have a confirmed 0x940C error then it is most likely that I had.

And I do hope that we all are talking about a 0xC940 address (and that 0xC904 is a typo).

Happy 75th anniversary to one of the best movies ever made! Rick Blane [Bogart]: "Of all the gin joints, in all the towns, in all the world, she walks into mine."

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:
And I do hope that we all are talking about a 0xC940 address (and that 0xC904 is a typo).

All I've seen or had reported were 0x940c.

Magnus Wessberg emailed me IIRC that about 20% of his 90 students had this problem and that they were using rechargable batteries and he could consistently get the problem to happen at 2.7V.

I suspect that there may be multiple causes, mostly the volt thing, but obviously in John and Gwens cases it wasn't the voltage.

A fellow at Atmel was looking into this, but he couldn't reproduce the problem. I don't know if he is still following the thread, but the idea of Atmel reverting to the old code is a good one. Now if we can just get their attention.

Then again, it >is< only 20 bucks, and even purchasing a AVRISP yields a $50 buck system that is still cheaper and more versitile than anything out there.

Smiley

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

what are the chances of ESD causing fuses to be set or cleared? its such a small board and seems easy to accidentally touch some component leads while handling it.

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

I would imagine less-than-zero. Setting the fuses required either the bootloader via code, or the parallel/SPI programming interfaces. Both are reasonably complex, both require very specific non-random conditions - in the case of SPI, you need four sucessful byte transfers to set a fuse. That means you need 64 pulses to the SCK line while feeding in the correct bits to the MISO pin of the MEGA169. Parallel requires equally difficult circumstances to set the fuses.

Having said that, for all I know there may be a bug in the silicon which causes spontaneous locking. I wouldn't put money on it, though.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

I hate to be pedantic (no you don't, you love it) but how can the chances of anything be "less-than-zero"?
Close to zero, possibly even zero (although I doubt it, infinite monkey business etc.) but less than zero?
What are the odds of the existence of negative probability?

Quebracho seems to be the hardest wood.

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

Since probability deals with the percent of occurances over a unit of time, if the time is negative then the chances will be less than 0. So what Dean is saying is that there is some chance that the event will occur in the past, even though it hasn't actually occured yet. I guess that a tachyon from the present could hit a fuse bit transistor in the past so that the Butterfly that was working properly suddenly wasn't actually working properly afterall.

And congratulations on your new child.

Smiley

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

I see.
Does this have anything to do with the so-called "Butterfly effect"? Once summed up by a smarter-person-than-me as "A scientist flaps his mouth somewhere, causing a storm in a teacup"?

Quote:
And congratulations on your new child.

Thank you, I was inspired by the new "avatars" of zoomcityzoom amongst others. He's actually adopted, his biological parents rejected him because he is missing an ear.
[Edit] Sorry, I just re-read that and it sounds like I'm accusing zoomcityzoom of earful assymetry. That was not my intended meaning.

Quebracho seems to be the hardest wood.

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

Hello Freaks,

A simple practical question.

I have 4/12 Butterfly devices that have been locked by bootloader corruption. I program with ARVProg 'via' (I like this word) RS232 interface.
Is that possible to restore them with Buttload?
I yes, what are the connections to the slave?

Do I have to reprogramme the bootloader section?

Daniel

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

You do not have to reprogram the bootloader section (at least I didn't anyway) just do an ISP reprogram.

Buttload will requre a working Butterfly that has the Buttload code on it and a flat cable. See Dean's posts.

You could also use an AVRISP or STK500.

You should also yell at Atmel. Look earlier in this thread for the guy who was looking into this.

Smiley

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

Is the OP asking if he can restore the other Butterflys using one Butterfly with BUTTLOAD loaded into it ???

Or does he ask if "Loading" BUTTLOAD into the dead Butterflys would restore the bootloader ??

I would suppose that a BUTTLOAD could LOAD the dead BUTTs

But i don't know if Dean's proggie incorporates a (The) bootloader.

/Bingo

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

Bingo,

I personally reload the bootloader separate from reloading the Butterfly code. I also check that the fuse/lock bits are set properly, in fact, that may be all you need to do to fix the problem.

I don't know if Deans code separates the bootoader from the rest or has it all in one package. Dean?

Smiley

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

I'm now thinking the ButtLoad name was a bad idea because people assume it is in fact a bootloader (other bootloaders have names such as MEGALOAD) rather than what it is, software to convert a Butterfly into an AVRISP so you can reprogram OTHER AVRs.

If you have one working butterfly, you can program ButtLoad into it, connect it up to the others and reprogram them assuming they can be repaired using standard ISP commands. You could also I assume load the Bootloader into the butterfly's non-volatile storage and use ButtLoad to program it into another butterfly without a computer - but i've never tried storing and programming a bootloader application. So long as it just sits at the top of the memory and doesn't use anything out of the ordinary, it should work fine.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

I'm now thinking the ButtLoad name was a bad idea because people assume it is in fact a bootloader (other bootloaders have names such as MEGALOAD) rather than what it is, software to convert a Butterfly into an AVRISP so you can reprogram OTHER AVRs.

Oh, so the object is to dump info into another AVR from a Butterfly? Then it should be ButtDump, eh?

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 should really compile a list of all these jokes and include them in the ButtLoad manual. Or perhaps not. Even if my project has achieved nothing, I shall rest assured that I will be seeing much rear-related-humour in the comming months.

Now lets stop arsing around and get back on topic :D.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:
Is the OP asking if he can restore the other Butterflys using one Butterfly with BUTTLOAD loaded into it ???

Or does he ask if "Loading" BUTTLOAD into the dead Butterflys would restore the bootloader ??

I have planned to restore the Butterflies using another one in which I loaded the ButtLoad.

I didn't get the wiring for lines /CS and /RESET.
As far I understand:
- /RESET (PF6) is connected on Slave Butterfly reset pin (J403.5)
- /CS (PF7) is connected on Slave DataFlash Chip Select (J400.1) PB0.

What about the reset pin of the Slave Butterfly DataFlash (PE7 on CPU) ?

Daniel

Pages