How about the 13th post down from the top of the ninth page of this thread. Sorry, I don't know how to do the hyperlink (or whatever it is called) thingie. If that doesn't work try a search on member "eieland" (without the quotes). He/she only has 13 posts so it shouldn't be but so hard to find that post.

Okay, I have ButterFly locked up again!
Please, no Flames this time!
I'm trying to be helpful...read on.

I'm either the owner of some very "touchy" BFs or my setup here is problematic. The DB9-DB9 cable I am using is rather long and looks fairly thin so I don't think there's much sheilding. I have four computers side-by-side and at times the monitors interfere with each other, so there's a lot of EMF. I also have Flourescent Lights which make some circuits go crazy. So to put a fine-point in it -- I glow in the dark.

This seems to point to the possibility that garbled xmission of data is probably the main culprit. I get a lot of BF lock-outs.

I don't know much about fuses and locks yet, but as promissed I am going to enter the data as read from a "locked" ButterFly using Dean's excellent ButtLoad program loaded into another ButterFly. (I have not setup my STK500 yet).

I hope you find this information useful and would appreciate feed-back

That's stopping the bootloader from writing new data to the application flash space. When you unlock the Butterfly, can you follow the sequence I posted earlier, loading in the bootloader into ButtLoad's storage and then reprogramming the locked butterfly via that? I'd be interested to see if it works...

- Dean :twisted:

PS: ISP fuse is disabled (gray box) because you cannot use the ISP interface to disable itself for safety reasons.

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

Okay what I did was restore the locked ButterFly to the original program that was shipped with these units when new, then went into AVRISP and read the Fuses and LockBits and the only difference appears to be with the LockBit:

[v] Application Prot Mode 1: No Lock on SPM....

So it would appear that this LockBit took the Functioning ButterFly from App Protection Mode 1 to App Protection Mode 3.

Okay Giorgos. The ButterFly locked up after just a few attempts.
I seem to have the "perfect" setup for making these things fail.

I just re-read the setting with AVRISP and the only change again appears to be
the change in LOCKBITS from Mode 1 (No Lock) to Mode 3 (LPM & SPM prohib...)

I hope you find this info useful. Is there anything else I can do to help you nail-down the problem?

I also noticed that it had "problems" starting my little program.
Is there a difference in the start-up sequence between GeoLoad and Original Software BootLoader? I'll try to describe... with original SW after I loaded my program I hit nailed RESET pin and press Joystick and my program starts no problem.

With the GeoLoad V11(L)I would have to RESET CHIP several times and press Joystick up before I could get program to start up.

Please understand that I am in no way complaining at this point, I'm only trying to be helpful. If you would prefer we could take this to private mail(?)

Dean I am trying to locate those instructions.
Also, is there anything else I can do before I restore this locked BF?

If all I'm using is the PC Serial/DB9 and the UART set-up as described in the ButterFly Documention using "AVR Prog" there is no way that any of these BootLoaders should allow me to change any of the fuses or lock-bits, on my own correct?

Hi RetroDan. I was going to ask you what bootloader did your Butterfly have, during the lock-up, but you have already answered this to me!

Of course I use a different approach! Let me look at this, though I have not received yet my Butterfly unit, to experiment on the real hardware. Until then, you can use the failsafe "ButterflyBoot v1.1.hex" firmware, that does not have the Lock-bits writing feature enabled.

If it is any help what I did was dump the contents of "Locked" ButterFly which has your GeoLoad v1.1L and my little program to a Hex file (45K) would that be any help to anyone? Can you re-load it and disassemble it to see what the problem might be?

You say the previous GeoLoad V1.1 has the writing feature totally disabled? Okay I'll try that one next.

When this problem first appeared and I was down to my last functioning (and unused)
Butterfly I used the SAVE PROGRAM feature inside AVR Prog and dumped it's contents to a HEX file then went out on the Internet on my wild escapade looking for a solution; which after a few days led me here. I did NOT want to screw-up my last remaining BF.

So after getting Dean's ButtLoad program into the "Virginal" ButterFly (as that was the only one I could still program) he was kind enough to walk me through the procedure of reprogramming the "Locked" BFs by using the AVRISP feature of his software.

Since that time, whenever a BF "Locked" I would grab this "Extra" BF with ButtLoad on it and quickly re-program it using the HEX dump from the Virgin BF. I did NOT switch to the older BootLoader.

Now that there are 2 more BootLoaders: Giorgos' ASM version and the "Official" new version from AVR -and- since I seem to some "quirk" in my setup here that seems to be able to force these things to fail on a regular basis, perhaps it's an excellent way to test-out these new versions.

I'm trying Giorgos' GeoLoad 1.1 version at the moment. If it lasts more than a day, then I would declare it a success as even on the best of days, I seem to be able to get a failure within a few hours and sometime after just 2 or 3 "burns."

I hope this information is useful and if anyone thinks it will spark another flamewar, I'd be glad to move to private mail.

Just a small point but you also have an STK500 don't you? Rather than trying to juggle the Butterflys wouldn't it just be easier to ISP all three back to default (but maybe with Giorgos' new bootloader) using the STK500 ?

I would appreciate it if you could get the old bootloader from: http://www.siwawi.arubi.uni-kl.d... and download it to your failing Butterfly using Dean's ButtLoad and see if that older bootloader is also failing. The reason I ask is that this is the way I've been recommending that folks fix their 0x940c problem and it was the basis for Atmel's decision to change the bootloader on the next batch of Butterflies. If you do have a case where this fix doesn't work, then we need to know if your situation is a special case or if we haven't actually solved the problem. I suspect that yours is a special case since I've put the old bootloader on a number of Butterflies and not had the 0x940c problem return.

Also, in these more recent failures you've experienced, did you get the 0x940c error?

I just ordered my BF today from digikey, I will take some time to see if I can have the same problem as RetroDan... Also I was thinking about an application similar to the ButtLoad, but instead of using the serial com, I was thinking using I2C. We'll see.

This thread is marvellous.!!! I really like it.. I have been learning alot form just this one... :wink:

I forgot to mention that I also ordered the BF carrier... seem to be a handy tool... do you think that I should order another BF, in case that fail?.. well I also ordered the STK500 so I guess would fix the lock-up problem, if it appears!

I'm delighted to see that this thread has inspired you. My fear was that it would scare people off.

As far as extra Butterflies, I personally do all my development with at least one Known-Good-System (KGS) sitting next to my System Under Development (SUD). Then if I come to a real puzzler, I can revert to the SUD which with Butterflies this is especially good in isolating a problem to the PC or the cable or the Butterfly. If something still works on the KGS but not on the SUD then I've put a fence around the problem (usually).

The real trick is getting the KGS working first. Some folks have had a regular nightmare getting started with the Butterfly in that you have so many things that can go wrong. Is it Brays terminal set up wrong?
Is it an odd RS-232 cable?
Is it the way you've soldered the DB-9 connector to the Butterfly?
Is it the Butterfly hardware? Is it the Butterfly software?
Are you just cursed and need to get a job at McDonalds?

It seems 99% of the folks get the Butterfly going right off, and the other 1% just get driven nuts by something that turns out to be very simple (like forgetting to check the CRLF box on Brays). Of course some of those 1% start off nuts, which may explain a few of the problems I've seen.

Also the Butterfly Carrier is an excellent way to make the Butterfly more robust and easier to expand. I use it in several professional development projects.

I agree, to get going the first time can be a struggle unless you just happen to luck into
getting everything perfect the first time. And there a few gotcha's like me pressing, but NOT holding down the joystick button in centre position to get AVR prog to see the device.
Musta' made 1/2 dozen cables before I figured it out. But then again...

1) Start ButtLoad
2) Enter STORAGE MODE instead of AVRISP MODE
3) Program in the bootloader of your choice into STORAGE MODE. The Butterfly does *not* have to be connected to the target at this time.
4) Exit STORAGE MODE, connect ButtLoad to the target. Enter PROGRAM AVR mode.
5) Select DATA ONLY from the list. You should see "PRG>D" shown on the display briefly before a sucess message.

You can use STORAGE MODE just as it was the target (including fuses, EEPROM and lockbytes), and then download them to the actual chip at a later date via PROGRAM AVR. I've never tried it with a bootloader before, so i'm interested to see if it works.

- Dean :twisted:

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

I just ordered my BF today from digikey, I will take some time to see if I can have the same problem as RetroDan... Also I was thinking about an application similar to the ButtLoad, but instead of using the serial com, I was thinking using I2C. We'll see.

This thread is marvellous.!!! I really like it.. I have been learning alot form just this one... :wink:

You mean I2C data in, serial data out? I could add in that to ButtLoad, but I currently have the restriction of codespace - any more code and i'll start encroaching onto the bootloader's space and thus prevent those with bootloaders from running my code. I was actually thinking about removing Direct Dataflash support from ButtLoad to free up space, since that feature will probably never be used and can be replicated via the AVRISP mode's SPI COMMAND feature and clever computer software anyway.

- Dean :twisted:

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

I connected ButterFly with ButtLoad to PC via serial DB9.
I disconnected the 2nd ButterFly.
I then I downloaded various BootLoaders into the ButtLoad BF's memory.
The I disconnected the ButtLoader from the PC and connected it to 2nd
BF via ISP port.
Not knowing what I was doing, most of the time I think I selected ERASE before
I tried to reprogram problem BF, because most of the options said things like Data ONLY and EEPROM only and the problem is with the Fuses/LockBits(?)

Anyhow all I ever got was Sync-Errors. So as of right now I can't say one way or the other if it works. Seems strange that same connections will allow me to reprogram problem BF from AVR Prog but not from ButtLoad. I do intent to try again after I get feed-back from you on procedure. You say I only use the Data Only Option without Erasing
first?

Anyhow, I can say with a fair amount of certainty that the new "Official" bootload from AVR seems to be extremely well behaved. I have not had a single problem in about 60 burns so far today and the failure rate prior that was about 1/10 to 1/20 burns.

The storage mode, being unique to ButtLoad, seems a little temperemental. I've found that in any cases cycling the power to both the target and ButtLoad will clear up the sync error but I havn't had time to track down the problem in-depth. I'll be leaving for a two week holiday to China with my family on Tuesday, and so will be unavaliable during that time.

Yes, DATA ONLY is all you need, as it performs an erase automatically. DATA ONLY programs the target with the program data stored in ButtLoad's memory, EEPROM ONLY programs just the EEPROM stored in memory, and the LOCK and FUSE settings program in the respective stored lock and fuse settings from ButtLoad's memory.

See if the power cycling fixes the problem. If not, i'll see if I can set some time aside today to check it out on my end and see if I can see what's causing the sync errors in some cases.

- Dean :twisted:

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

Next time I try I will make sure both ButterFlies have been Freshly Reset and I will just use the Program Data Only Option.

Perahap, to make your program more robust, just skip the error checking and just go ahead with the "burn" anyway. I don't imagine it will harm anything will it? That might save you some valuable programming space and if it fails to burn another chip the guy is going to check his cables, etc anyway.

What I was thinking is to design a "mini"-buttload with the capabilities similar to ButtLoad "STORAGE MODE", so the user will store the firmware into the dataflash(using AvrStudio), then the user will carry the BF to a given location, and use the "ISP MODE" to change the firmware of the failing product, but the "ISP MODE" that I will use is using the I2C protocol instead of the SPI protocol... obviously this implies that the "product" needs to have a bootloader that understand I2C...

Well, I am still brain storming this idea... thanks for the inspiration.

Hi. Don't miss the latest "ButterflyBoot v1.2.hex" enhanced Butterfly bootloader firmware release.
With power management (down to 40% of the power consumption of the Rev1.1 and the official ATMEL's firmwares) and an improved programming engine, that probably eliminates the 0x940C bug.
Get it here: https://www.avrfreaks.net/index.p...