The ButtLoad V1.1 (currently unreleased) combines the /CS and /RESET functionality into a single pin.
If you wish to program a slave dataflash using ButtLoad 1.0, connect the slave dataflash's SPI pins to the USI port of the butterfly, connect the /CS pin to the ext. /CS pin shown in the manual and connect the dataflash's RESET pin to whatever level keeps the dataflash active. All resetting and such for external dataflashes are performed via software.
- Dean :twisted:
Make Atmel Studio better with my free extensions. Open source and feedback welcome!
AvrProg always reads the entire flash contents, including that which the bootloader is located in. Is it possible users are reading the chip before programming again? I don't think AvrProg does any checking other than for the absolute flash limits. It seems that trying to write over top of itself could cause all kinds of strange behavior.
Just a thought....
I'm a nrebie having the same problem with verify on a Butterfly. It is a small program that just makes noise come from speaker. Probably 20 - 30 bytes long, so a large program is probably not the problem.
The same error occurs when I try to write to EEPROM.
However, If I plug in another Butterfly with same program, it writes and verifies with no problems.
Could the problem have originated with batteries? The one that I am having problems with had been reprogrammed quite a few times and the one that still works is fairly virginal. I replaced the battery in "defective" one but problem did not go away. Is it possible that low battery condition caused a problem on a previous write and now problem is permanent?
We so far have not determined a strong and definite link from a cause to the problem. It has been suggested that low battery power may cause the fault, although it has occured using externally supplied power, and so it cannot be blamed soley on a bad battery.
Your Butterfly is most likely *not* dead. The problem is where the bootloader spontenously locks the MEGA169 from further programming, which can only be rectified with ISP or JTAG programming. If you have a working Butterfly, you can download my free "ButtLoad" firmware which will turn the working Butterfly into a AVRISP so you can fix the dead one.
Fantastic, thank you very much for the reply.
I would very much like to try your Buttloader program however, you did not mention where I can download it. I'd really like to find a practical solution because not only do I have an unprogrammable ButterFly. I'm now afraid of using the other one for fear of same problem.
Since leaving the previous post, I have had a chance to read the entire thread.
In my opinion the problem is two-fold, the new bootloader allows the changing of locks without much error checking, and it would appear than courrupted data, mostly caused by a weak battery or perhaps by the switch "bouncing" and/or interupted connections caused by us hacks holding the tiny things in your hand and possibly moving them around during the programming.
Perhaps the reason AVR can't replicate the problem is that they know better than to hold the thing in your hand while programming. I've seen various characters displayed on screen just from touching pins during programming, so I hate to think of what kinds of corrupt data its trying to deal with.
Touching the pins, low voltage, jiggling home-made serial cables, etc. combined with new bootloader would appear to be main cause.
They really should have this problem fixed extremely quickly. In my case I was trying to decide between AVR, PIC, or Z8 and ordered the BFs to evalute AVRs in general. I see the BFs as an entry-level product and it could be turning 20% of potential clients away.
When problem first appeared I was well on my way to switching to PIC or Z8 Encore.
After reading these posts, it seems to be just an issue with the appication and not a problem with the chips themselves, however three emails to AVR regarding the problem have still gone unaswered.
ButtLoad is avaliable from http://www.avrfreaks.net/index.php?module=FreaksAcademy&func=viewItem&item_id=517&item_type=project. I've just found out it's incompatible with older AVRs due to a bug, which i'm working on fixing, but it should be fine for MEGA169s. Let me know how it works out.
however three emails to AVR regarding the problem have still gone unaswered.
I suspect they have grown quite weary of these problems....from a product
they undoubtedtly sell at a loss just to get a cool AVR board into the hands
of potential future customers. Once you can reload the bootloader you will
have no more trouble from the butterfly...aside from this one problem they
are quite robust.
AVRs are way better than PIC..I know the PIC and I swear that it's the truth.
Z8 thingies I don't know...but I bet AVRs are way better than them too :)
Okay, thanks. I've downloaded your Buttload program and the Old Bootloader 20040127 that everyone seems to agree is the most stable.
Just to clarify: What I should do is "downgrade" my last remaining working ButterFly with the old bootloader HEX file using AVRprog. Then I should load your Buttloader HEX program using AVRprog and from there I guess there's a way to load the Old Bootloader for Buttloader, then I will need to fabricate some sort of cable to go from functioning BF to non-Funtioning BFs and then downgrade them also to the old bootloader and restore them to health?
If that fails, isn't there a cable or minimal programmer than one could throw together from parts drawer that AVR prog will recognize? Perhaps a parallel to ISP or perhaps the COM/Serial connection through a level shifter into ISP? There's got to be a better way than buying an STK500? It's a chicken and egg problem. You get the evaluation BF BECAUSE you're not sure if you want to invest in the STK500 then you need to buy the STK500 to get the BF working? Great SCAM if you can keep it going.
As for the Zilog Z8 Encore -- for $50 Canadian you get COMPLETE devlelopment system, software cables, board etc. and reports I get are that within 5 minutes you can have a program compiled and programmed with LED BLINKINLITES. The ONLY reason I did not start there is that I was erronously told that the BFs where a development platform. Imagine my face when I opened box to see NAMETAGS!!! Where is the software? Where's the cables? Where the friggin' documentation? -- I was convinced they shipped out the wrong items.
Yes, that's correct, although downgrading the ButtLoad Butterfly isn't strictly nessesary (but should prevent future lockings). Because ButtLoad is a app and not a bootloader, the existing bootloder is preserved. Once finished with ButtLoad, you can use SETTINGS->JUMP TO BOOTLOADER, or cycle the power to get back into the normal bootloader and download a new application to the butterfly.
Okay, a progress report...
I think I downgraded the bootloader (but how can one be sure?) on my last working BF.
I have loaded your ButtLoad.hex file several times and cannot get the BF to respond.
I have shorted reset pins, and also did a power-down reset and held the joystick up with no response? Is it possible your program is not compatible with older bootstrap, or am I just another STUPID newbie doing something incorrectly?
BTW, while re-programming your Buttload.hex a couple times I got the dreaded 940C error, and thought I had "pooched" my last remaining BF (where's my shotgun!) however,
the BF recovered both times, perhaps it was a good thing that the first item on list was downgrading the bootloader(?)
Well, I'm finally at a dead-end. What next, should I try a re-compile of your source code?
BTW. when programming HEX file it says its entering Boot Area, is that okay?
You did push the joystick upwards after programming in Buttload, didn't you?
EDIT: Bugger, didn't read your post right :D. ButtLoad should be compatible with all Butterflies. Upon activation, you should at least see the "*WAIT*" message.
Sorry, tried to re-compile your source-code but AVR STudio complains that I need to install something called WinAVR? Can anyone comment?
Can anyone explain why I can't take RX/TX from PC Serial port, drop the voltage to 3 volts and feed them into ISP port? Would AVR prog see it? How does one tell the '169 bootloader that data is coming in on ISP and not via UART port?
No the BF is totally dead when ButtLoad is installed.
This is about my 8th attempt and do reset the chip and hold joystick up, but there is no "WAIT" displayed as per your documentation.
As I mentioned before, when programming your program, AVR prog complains that its entering the Bootload area... is that to be expected?
Hope I can help you sort this out.
ISP is totally, completly and utterly different to serial, hence the requirement for a smart translator such as ButtLoad. Is **IS** possible to "bit bang" ISP data from the serial handshake (not data) lines, however that method is EXTREAMLY slow - you're looking at an hour a program in some cases. You'd be better of making a simple parallel port ISP dongle, which can be temperamental but can work quite well in most cases.
Where do you live?
Oh hang on - did you cycle the power? After downloading, you need to remove the battery, reinsert it and THEN push the joystick upwards. I'm not sure if I included that step in the manual :?.
I'm in lovely London, Ontario, Canada thank you for asking.
How confusing. Isn't ISP a serial protocol also? Actually, for us little guys, an hour to restore a "broken" BF is not that bad. You'd only need it once to retore bootloader correct? Then they could move back to using UART.
I've got no problem throwing together a parallel interface. I've got schematics here for two, however, the point is mute if AVR STudio will not recognize them. One of them has no parts, just connects half-dozen parallel lines to ISP lines: Pin7 (RESET), Pin8(SCK),PIN9(MOSI), PIN10(MISO), PIN18(GND) the other uses a few resitors, caps and a 74ls245 Tri-State Buffer.
ISP is a serial protocol, but "serial" just means that the data is sent in one long stream. The actual transfer method, and data, is very different (think how AC and DC current are both electricity, but different).
Freeware applications such as "PonyProg" and "AVRDude" off the internet can drive most of those parallel programmer designs. I'm still suprised that ButtLoad's failed for you - it's worked fine on all three of my Butterflies. Did you power cycle the Butterfly before pushing the joystick upwards?
WinAVR is a collection of free AVR tools (AVRDude included) avaliable from SourceForge.net. Principal to the package is the AVR-GCC free C compiler for AVRs on which my code is based, and with what AVRStudio requires to recompile my project.
I'm not sure about the bootloader thing, but I don't think the bootloader can reprogram itself, so you should be fine. Which raises the question - how did you downgrade the bootloader without an ISP programmer? Chances are you just loaded the new bootloader into the application section, which just got deleted when you programmed Buttload. I don't know, i've never tried using a bootloader to change the bootloader.
Yes I cycled the power... don't worry, you made it quite clear in the docs.
I built an external battery supply (just in case the problem is weak batteries) and installed a small switch that shorts the reset pin to ground, but just on the odd chance I'm going to try a full power-off reset to see what happens....
Sorry, dead as a door-nail!
Just to be clear... your program should start-up and initialize without having to connect to other BF beforehand, correct?
Just in case you want to try an duplicate this error I first programed the bootloader hex file under "bf_boot_20040127/from_org/AVR_Butterfly_Bootloader_rev02.hex
Then I porgammed the ButtLoader from the link you had at the bottom of your message:
I checked your main.c but don't see a version number or revision history however the main.c file is 28,364 bytes if that is any help.
The version number is contained in Main.h, but it must be the latest version. In any case, any version should get you up and running.
Yes, ButtLoad should start immediatly once activated, whether anything is connected or not. On startup "*WAIT*" should appear no matter what. I'll see if I can duplicate your problem tomorrow, it's a bit late tonight.
Can you program anything else into the butterfly via the bootloader?
Hmm, you raise a good question. Perhaps I have NOT upgraded my bootloader, afterall there's no real way to tell is there?
I tried the AVR DUDE with -p m169 -c butterfly without success. In fact I went through a huge number of parameter combinations... I could not even get it to respond to the -t Terminal Command. From follwing other posts I'm not sure that AVR DUDE would work for the butterfly.
Oh yes, I have programmed various stuff before, after and in between trying to install ButtLoad.hex but I'm quite nervous as I do not want to kill my BF before a reasonable solution is found. I'd sure like to get back to learning how to program these things without having to white-knuckle it everytime I do a reprogram!
Good night, Good morning and have a great week!
Make a simple parallel port programmer out of three resistors connected to the MOSI/MISO/SCK like in my manual (link in sig, check the schematics section). You can then use AVRDude with the "hotchip" programmer mode to re-flash the Butterfly.
You can not load a new bootloader using a bootloader. Actually it is possible, but it requires things to be setup beforehand to allow this, which I believe requires the bootloader section startup to be set at a location that would give you room for 2 copies of the bootloader. This allows one to be running while writing a new one :)
In any case, I don't think this is an option for you at the moment.
It sounds like your only option at the moment is obtaining an ISP programmer. There was mention somewhere in this thread of someone building a parallel port version that was succesful.
May be a place to start?
Ya know what, maybe I should just say to heck with it!
Who needs the hassle. I've wasted an entire week-end and in the end they're nothing but a pile of useless junk (with the exception of the single one that has not died yet.) And no one seems to have a reasonable solution.
Well Gentleman, I must say in summary that I am NOT impressed.
If they designed the Butterfly to showcase their product line, service, etc.
I must say that it's a TOTAL FAILURE. I'm second guessing my purchase of an STK500 and think I'll just go with another company. These days one chip seems to be just as powerful as any another. There's always the PICs, and also the 8015s, and what ever happened to all those Motorola 68 series, and the new Z8 from Zilog, etc.
From reading these posts it seems that there is at least 20% failure rate that's been reported for over a year, and all they can say is they can't duplicate it in the lab!!!!
Why do they need to do that, can't they just take our word-for-it and switch-over to finding a solution?
Why don't they at least change the present bootcode, or at a very, very minimum offer a small program and instuctions for a simple cable that will at least restore the bootloader when one of these goes awry? Or how about a free replacement if you send in a dead one? They've had over a year to correct this problem. They haven't even bothered to acknowledge my three emails to tech support about the problem. Good thing I found this Forum, or I'd be running in circles, ripping out my hair and loading my shotgun.
...maybe I should just say to heck with it!
You can get through this...
I started with the Mega8535 and an ATAVRISP about two years ago. I'v had zero issues exbept that, I ran 12 VDC into the ATAVRISP while debugging and smoked it. AVR's really are good microcontrollers. I have used many different microcontrollers ofer the years including, F8, Z80, 6800, 6801, 68701, 6502, Segnetics 8X300i and, some I can't remember the numbers of.
The AVR Mega family is, in my opinion, the best 8 bit machine out there.
I deliberately chose the ATAVRISP and the Mega8535 and, later the STK500/501 because I wanted the assurance that I could reliably program the microcontrollers.
Actually, I purchased a DDS system kit from the Dayton Ham Fest that used an AT90S3213. The odd thing is, I had to download the source code from the creators web-site and program it myself, so, I was forced to get the ATAVRISP if I wanted to use the DDS system.
Well, it was well worth it. When I say how easy it was to write programs and download them into the AT90S2313, I imediately abondend the MC68HC11 and moved over to the AVR.
I'm sorry for your bad experience but, maybe for the price of the three Butterflies + $20.00, you should have purchased the STK500 right up front.
I have seven Butterflies but I haven't had the time to really play with them on the bench, other then use one for a temperature monitor and play with the menu. Oh! I did manage to put my name in it.
Hang in there a while longer. Dean will more then likely be the one to help get your problem resolved. Give him a chance and don't render all of his efforts null & void.
You can avoid reality, for a while. But you can't avoid the consequences of reality! - C.W. Livingston
 Self Censored [/edit]
LOOK IN THE MIRROR?????
How rude can one person get? YOU were the one that told me about the problems with the Butterflies locking-up when the batteries get low! Now it's MY fault all of a sudden?
What about the next poor sod, who's BF locks up on him? Is this going to be your advice to him too?
LOOK IN THE MIRROR????
Anyhow, despite the cheap shots from unnamed individuals, Dean and his ButtLoad program was able to revive the failed ButterFlies and I am quite happy.
I had originally planned to start with the STK500 until another unnamed individual convinced me that the BFs were an excellent Starting Point.
Some unnamed individuals accused me of being too cheap... if I was that cheap I probably would have only ordered one and not more, correct? I alread had the STK500 on order and just didn't mention it because IMHO a good solution needs to be found and certain individuals should be more helpful to the next poor guy in the same boat. Accusing them of being too cheap to buy STK500 or to "look in the mirror" is not a real solution in my humble opinion.
PS. STK500 arrived this afternoon along with Z8 Dev KIt. So now I'm more than happy... I'm ecstatic.
Retro, i'm sure Smokey's just upset that you insulted his greatest passion. I fully understand both his reaction to your frustrated comments and your reason for posting them.
I hope your STK500 brings you sufficient joy that you are able to return that Z8 kit to where it came from :).
Smokey, why don't you offer, for an extra few dollars, to preload the older bootloader onto purchased Butterflies so that those new to AVRs don't get the problems? It would be a valuable service, and i'm sure one that people will jump all over.
Retro's learning quite nicely, and i'm certianly encouraging him. He's certainly not another sparksandtabs...
PS: Butterflies *are* a good starting point, apart from that occasional glitch.
I think that's an EXCELLENT solution. It might throw some extra business his way also. I'd certainly point newbies towards the trouble-free version.
Call me naïve but I think we might get some movement on the bootloader issue. A couple months ago I called Digikey about a firmware problem with my AVRISP. Frankly I was blown away by the knowledge, ability and helpfulness of their product specialist.
So I got to thinking and said to my self “Self -- Digikey is going to have a lot more pull with Atmel than any one of us.” So I made a call and had a nice long conversation with Josh a product specialist for the Atmel line. He listened very eagerly and though that the problem was certainly one that would have an impact on their customer satisfaction and customer support costs so he is going to give Atmel a call.
So my question for you all, Josh (product specialist at Digikey) asked me what I would want them to do. I said that at least two things had come up in this list. One, go back to the earlier code the second go with George K’s new code. I suggested that the community was probably doing a pretty good job of testing George K’s code and that one option would be for them to pay him for his code.
They are going to get back to me early next week. I will keep you informed.
An excellent idea! I did order mine through Digi-Key and had the defective (or what I thought were defective) Butterflies all packed-up and ready to be returned. Unfortunately it was late on a Friday and I had to wait until Monday. However in the meantime I started searching online and discovered that they wern't defective per se. But locked with no quick way to unlock them.
With a more robust bootloader I think they would be a FANTASTIC product for anyone.
I do think it would bring many more people into the AVR "fold". I think it's very wrong to consider them a none-profit device when those who are happy with their Butterflies soon move up the product line. It's probably the ultimate little toy to convert PIC or 8015 programers over.
If you follow my posts I just about gave-up on the whole product line just because of a small software glitch. I'm converted now but I did order a Zilog Development System at the hieght of my frustration (Its still on the shelf un-used)
Well that's my 2 cents!
BTW if it's a penny for your thoughts but you put your 2 cents in... who gets the profit?
We have now reduced the functionality of the AVR Butterfly bootloader (ie. removed the possibility to program the lockbits). This should prevent people from encountering this problem. We have testet this bootloader on several Butterflies here in the office today and even when deliberately trying to program the lockbits, we were not able to change them.
I have attached the new bootloader to this post and notified our manufacturer, so that new Butterflies will be shipped with this bootloader.
Atmel AVR Technical support
Follow me on the birdsite @AndreasMCUguy
I work at Atmel, but I try my best not to add marketing fluff in this forum.Hopefully I succeed. Views are my own and does not represent Atmel --
Thanks Andreas. Although I expect the new bootloader written by Giorgos (http://www.avrfreaks.net/index.p...) is much smaller than the official one, I'm also sure that new users evaluating the AVR line with the Butterfly will thank you for not having to go through the same trouble as everyone else :). Huzzah to progress, or in this case recession.
Hey, that's FANTASTIC!!!! Great that key people are listening!!
So there's FOUR options now.
1. Revert to previous original bootloader
2. Install this new "Official" new loader
3. Install Giorgos ASM Bootloder (probably smaller)
4. Install ButtLoad (with enhanced AVRISP Programming abilities)
Since Dean (and ButtLoad) solved my problem ButterFlies I think they are fantastic.
I only wish that DigiKey offered a volume discount on them. Last time I checked they were almost $25 each (CANADIAN) and I am super happy to hear that future ButterFlies will ship with new bullet-proof loader.
Soon as I get the chance I'd like to give it a try. I had one BF here that locked-up about 8 times in one night, and has locked-up a total of about 12 times in the two weeks I've had it. So it seems I have a particularly unstable one that should be a good test.
RetroDan, please allow me a correction.
So there's FOUR options now.
1. Revert to previous original bootloader
2. Install this new "Official" new loader
3. Install Giorgos ASM Bootloder (probably smaller)
4. Install ButtLoad (with enhanced AVRISP Programming abilities)
Therefore you can extended the Butterfly Application Section to 7679W (=15358 Bytes) instead of the 7167W (=14334 Bytes), the official bootloader allows you to:
If you wish, you can safely dedicate another one kilobyte of program memory to your application code! You can set it free by presetting the bootstart at the third position (512W, at address 0x1E00) instead of the standard fourth position (1024W, at address 0x1C00), by changing the boot fuses.
I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)
My most sincere apologies Giorgos.
Your bootloader is A LOT SMALLER leaving the user much more program space.
Thanks for verifying my thoughts. I suspected it was smaller but refrained from any claims until I knew the facts.
I'd like to personally thank you for the time you and your associates have invested in your wonderful solution to the ButterFly "lock-up" problem.
Have you given it an "official" name yet?
If I may be so forward how about:
GioLoad, GKLoad, or maybe uLoad for the ButterFlea
You are welcome.
LOL! I am open to its name suggestions!
Well I'm gonna' call it GeoLoad if that's okay with you Giorgos?
I've copied Andreas' response over to the condensed version of this thread in the tutorials section:
I think this shows one of the great values of AVRFreaks. This thread has been an interactive elaboration, exploration, and (hopefully) cure for a problem with a popular Atmel product. Not only do we help each other with our learning and using of the AVR, we are helping Atmel make its products even better. Every time I think about using another brand microcontroller, even if it has slightly better specs than an AVR, I say: 'Nah!' I'll stick with the AVR because of the incredible community support I can get at AVRFreaks. As much as I contribute here, I get far more in return.
Well done Smiley. Nice work.
New firmware update: "ButterflyBoot v1.1L.hex" released.
It is the fully functional revision of the stable "ButterflyBoot v1.1" release, with the Lock-bits writing feature enabled.
It is only 482W long, so it still is under the 512 Words barrier, and fits into the third bootstart position at the address 0x1E00!
You should consider consolidating this into a tutorial and posting it on the Tutorials forum, so that folks can keep track of this in one place. I think this has far more use than just to solve the 0x940c problem.
Another thing to bear in mind with Giorgos' loader, the small size allows one to add
additional code in the smaller boot memory section. I'm using it in a special purpose
application which requires that various port and user IO hardware be initialized so that
among other things, various text prompts can pe presented to the operator during
upgrade procedures. Nice! Thanks Giorgos!
Is the assembly listing shown on that page for the latest version of GeoLoad1.1(L)
Those BF that locked up -- what were the fuses set to when prior to
"unlocking" them? Just curious...
Van Alstyne, TX
Rusty Haddock = KD4WLZ = firstname.lastname@example.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking
I have Butterflies that lock-up regularly.
However, I am a newbie, if someone could guide me I could check the fuse settings before I restore them next-time.
Connect ButtLoad to one of them, then in the AVRISP programming window, select the fuses tab. It will read the target Butterfly's fuses automatically, and you can change any of them from that tab also.
Thanks Dean, what particular fuses should I be looking at?
Looking at the bootloader code, it seems it activates the lockbits, rather than the fuses (a fuse is set, however, which allows the bootloader to manipulate the lockbits) so next time you get a lockup, you should see the Lockbits in the appropriate tab set to something other than "No Protection".
I'm ready to start "slammin" programs into these ButterFlies again.
I'd like to tryout Giorgo's GeoLoad Version1.1(L) but I'd also like to try the new "Offical" one that's going to be shipped with new BFs.
However, stupid me doesn't know where I saw the link to download it?
Can anyone help?
PS. Any changes to GeoLoad 1.1L since I downloaded HEX File on March 8th?
Were there not a few last-minute changes for an AVRDude related issue?
If I am understanding your question correctly you can find a link to Giorgo's (sorry if that is misspelled) thread 9 posts (or so) above your post RetroDan (in this same thread).
©2015 Atmel Corporation