Enhanced Butterfly BootLoader

Go To Last Post
85 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After all this noise about the Butterfly bootloader failures, I took the liberty to disassemble the official "butterfly_boot_rev03.hex", where I think I have found a few minor inconsistencies and a lot of code bloating, of course.

I have written from scratch a new bootloader for the Butterfly unit, being guided by the structure of the dissasembled file above, and using the program flow of my fully functioning bootloader libraries.

I believe that you will be impressed, firstly by the firmware size: It is 938 Bytes only, or 469 Program Memory Words!
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.

This bootloader supports all the programming modes (Word mode and Block mode) at 19200bps for both the memories (FLASH and EERPOM), and responds faster than the original one. I have only disabled the Lock-bits writing routines, to ensure that nothing can go wrong, but they can be re-enabled by uncommenting the related code at the source file.

You might wonder why this file has half the size only of the original one. I have not removed any functionality from this bootloader. I have just written this piece of software in assembly. Please, don't get me wrong but I am not trying to start another one of those legendary, delectable though, Assembly vs. C wars, we always manage to have over here...

Unfortunately, I did not have a Butterfly unit available or an m169 chip, so I have not been able to test this piece of code properly. I have successfully tested though a slightly modified version of this code for the m162, which is the most related chip to the m169, I had in hand.
Please, let me know if you can see any strange behaviour or malfunctions. Provide me with the details in order to fix them.

I hope you will find this piece of software handy. Download your copy of the Butterfly bootloader and have fun!

George.

EDIT 1 (2006.Mar.06): Bug-fix update. "ButterflyBoot v1.1.hex" released.
Although the "ButterflyBoot v1.0" worked fine using the AVRProg front-end, it would not work properly using the Avrdude: Fixed.
The Write_Lock_bit command has been disabled, therefore the chip cannot be locked.
The firmware size is below the 512W barrier: Only 471W long!
Reference: http://www.avrfreaks.net/index.p...

EDIT 2 (2006.Mar.12): Major enhancements. "ButterflyBoot v1.2.hex" released: Low power consumption, and better programming engine.
Based on the "ButterflyBoot v1.1", using extensively the sleep modes to minimize the power consumption.
The Rev1.2 improved programming-engine must now eliminate the known 0x940C bug.
The Read/Write_Lock_Bits and the Write_Fuse_Bits routines have been disabled: They gave way to the power management routines.
Green operation: Extended battery life! Tests have been done resulted to lower power consumption: Down to 40% of the Rev1.1 and the official firmwares.
The firmware size is still below the 512W barrier.
Reference: http://www.avrfreaks.net/index.p...

EDIT 3 (2006.Mar.13): Note: I will have to withdraw the "ButterflyBoot v1.2" firmware release, until I receive the Butterfly unit I am expecting to, to test this new bootloader thoroughly.
Thank you for your support. I will keep you posted.

Attachment(s): 

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

Last Edited: Mon. Mar 13, 2006 - 09:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Giorgos_K :)

WoW! 1/2 the size!
You are a genius! :)

Just WELL DONE....

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

Thank you Gwen, but let's see first if it works...

Just kidding (I hope...)!

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Very Nice!......and it shows up as an ATmega169 BOOT now!(in AVRProg) Programs quick!


My AVR Site

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

Yes, LCD, this comes from the "CPU specific parameters" definitions. Check it out!
It does quick programming because the firmware supports the Block-modes.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Actually, yours is a quarter of the size of the official bootloader. The official release requires 1024 words (2Kb) of space which caused me much ButtLoad-related grief.

Great work! I was in fact just about to start writing my own. Does yours have error checking on the fuse and lock byte setting commands?

- Dean :twisted:

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

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

No, not mine nor the official program have error checking routines.

As I said before, I have disabled the Lock writing routines. If you like I can upload the fully functional .hex file. Download the .asm. It is very well commented (for anyone can understand my greeklish!).

George.

PS. As a Butterfly expert you are, can you please test my program extensively? I do not have a Butterfly device to do this on my own, and I would not like to afflict any unsuspicious users...

EDIT: BTW, this program may be -literally- mine, but it is also a free, open source software, I wish to share with the community. Read the included license!

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Sure, i'd be happy to test it out. I'll get back to you with the results.

I was tossing around the idea of cutting up ButtLoad to make a bootloader which uses a subset of the STK500V2 protocol. It would be more robust, and usable from the "Program AVR..." menu item inside AVRStudio (not AVRPROG). Of course some of the functions would be disabled due to being not applicable with a bootloader, but do you think it's a good idea? I could probably jam it into 2Kb...

- Dean :twisted:

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

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

Dean, in my opinion, it could be done in assembler. You can see how efficient the assembly can be. I'll see what I can do about the STK500V2 bootloader.

This bootloader I wrote is 100% compatible with the official one, and even better, though it is half the size of the original. No, I am not good; I am just a little better at this, than the IAR compiler seems to have been... Also, do not forget that this is a two-days-only project. It HAS TO HAVE errors...

Anyway, thank you for being eager to mess with this program! There is also my email at the source file, if you will need anything. Thanks again.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

This isn't version 2 but it is an STK500 bootloader.....but no source. I tried this out on my mega16.
http://hubbard.engr.scu.edu/embe...


My AVR Site

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

LCD, thank you for the pointer.
I can see that there is no source code but only the executables (the .hex). I think that it will be easier and faster for me to write my own code, snce the STK500v2 protocol is already public, than disassembling and struggling to understand those ones...

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Damn, all my ideas have already been done. Oh well, less work for me!

- Dean :twisted:

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

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

Dean, in a free distribution, open source software community, I think that this would not be a major problem.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Giorgos_K wrote:
Yes, LCD, this comes from the "CPU specific parameters" definitions. Check it out!
It does quick programming because the firmware supports the Block-modes.

Nice one ! I'll try to "port" Your code to GNU ASM / Mega168 and see how it goes ! (ie. is it faster than My M168 bootloader :-) )
Thanks for sharing ! (again: I miss a 'thumbs up' smiley...)

Stupid question: This word mode/block mode that keeps popping up when talking about bootloaders ? What's it all about ? As far as I can see there is only one way to use the SPM stuff (temp buf, page erase, page write...) ...

/J

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

Quote:
I'll try to "port" Your code to GNU ASM / Mega168

Yippeee! my favorite AVR :)

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

Thanks, Jussi

The Block-mode is faster because it reads from and wriites directly to the RAM. The com-talk is also in the faster burst-mode than in the slower single get/put.

Good luck porting it to GNU, because I think that it will become more readable for the vast majority.
I did not even try to do it, since I am much better at the assembly than I am at C. And I think that I do not even want to try to master the embedded C. Anyway, I know, shame on me, but this is who I am...

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

I'm going to be putting your bootloader through some rigorous tests. This is also to help in finding the real problem with a small percentage of BFs. I will run my Butterfly with just the low power coin battery.(this seems to be one hypothosis in the problem)


My AVR Site

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

Giorgos_K wrote:
Thanks, Jussi

The Block-mode is faster because it reads from and wriites directly to the RAM. The com-talk is also in the faster burst-mode than in the slower single get/put.

Good luck porting it to GNU, because I think that it will become more readable for the vast majority.
I did not even try to do it, since I am much better at the assembly than I am at C. And I think that I do not even want to try to master the embedded C. Anyway, I know, shame on me, but this is who I am...


Ok, so my bootloader operates in "word mode" then ... ie. receive a word into r0/r1, write to tempbuf, receive next word ... e.t.c ... until PAGE FULL -> ERASE/WRITE PAGE and start over again ...

Correction : I'.ve got no plans whatsoever to rewrite anything in C ... :-)

I'm currently using GNU ASM for my AVR stuff, and the syntax is a bit different from AVRASM ...
Getting Your code to work for the M168 shouldn't be too much of a challenge, but the AVRASM -> GNU ASM bit is a bit more "scary" ...
/J

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

Thank you, LCD

Be careful though, because I am not sure that my code is bug-free. It took me one day and a half to disassemble and sort out the official firmware, and the rest half of the second day to build mine. Especially because I did not have a Butterfly unit, to test my firmware, and did my tests using a similar MCU.

If you need anything, do not hesitate!

George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Quote:
Correction : I'.ve got no plans whatsoever to rewrite anything in C ...

Now, you've got me!!!

Porting the code to m168 should not be difficult, because I think that those chips' memories are the same. And if they were not, I do not use magic numbers; just trim the definitions.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Quote:

You might wonder why this file has half the size only of the original one. I have not removed any functionality from this bootloader. I have just written this piece of software in assembly. Please, don't get me wrong but I am not trying to start another one of those legendary, delectable though, Assembly vs. C wars, we always manage to have over here...

:lol:

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

jussishow wrote:
Giorgos_K wrote:
Thanks for sharing ! (again: I miss a 'thumbs up' smiley...)

Hey, I gotta sleep sometime!

So big thumbs up Giorgos :D

I'll put a link to this thread on the 0x940c problem thread, maybe it will help some folks with a susceptible Butterfly.

Thanks, of doing this, amazingly - even though you don't have a Butterfly!?!

Smiley

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

Why can't us bit-diddlers have our own little sandbox to play in?

The GCC guys have one, shouldn't there be an ASM one also?

Just a thought.

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

smileymicros wrote:
jussishow wrote:
Giorgos_K wrote:
Thanks for sharing ! (again: I miss a 'thumbs up' smiley...)

Hey, I gotta sleep sometime!

So big thumbs up Giorgos :D

I'll put a link to this thread on the 0x940c problem thread, maybe it will help some folks with a susceptible Butterfly.

Thanks, of doing this, amazingly - even though you don't have a Butterfly!?!

Smiley

He he ... Maybe I should have said 'I miss a 'thumbs up' emoticon...' :-)

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

RetroDan,
I believe the reason GCC gets it's own forum is because it is an open source user supported project and as such doesn't have the benefit of factory support like the other C compilers. Also the issues that ASM users encounter are often applicable to AVR users in general and those questions are redirected from the GCC to the AVR forum. If the forums were more divided much valuable information would be harder to find. BTW welcome to the neigborhood. I'm glad you didn't give up when you had problems with your Butterfly.

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

eejay wrote:

BTW welcome to the neigborhood. I'm glad you didn't give up when you had problems with your Butterfly.

Thank you for the welcome, it's well appreciated.

One of the reasons I almost dropped the AVR chips is because I didn't think I was welcome here AT ALL! I'm still staring at an unused Z8 Development Kit I ordered at the height of my confusion.(BTW- I'm still intreagued by Zilog's claim of 4K working registers! Wonder how orthoginal they are and what is the average clocks-per-instuction? Things that make you go Hmm...)

Anyhow, are you SURE you aren't glad I left.... I'd probably be harrasing some poor folks on a ZILOG forum somewhere instead of bothering this fine group of gentlemen!

As for the ASM Forum...I'm not complaining, I like it in here!
Just a suggestion to avoid the flamewars someone mentioned.

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

jussishow wrote:
smileymicros wrote:
jussishow wrote:
Giorgos_K wrote:
Thanks for sharing ! (again: I miss a 'thumbs up' smiley...)

Hey, I gotta sleep sometime!

So big thumbs up Giorgos :D

I'll put a link to this thread on the 0x940c problem thread, maybe it will help some folks with a susceptible Butterfly.

Thanks, of doing this, amazingly - even though you don't have a Butterfly!?!

Smiley

He he ... Maybe I should have said 'I miss a 'thumbs up' emoticon...' :-)

I just washed my ego and I can't do a thing with it :D

Smiley

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

It think it is the least I can do. Not that others can't go ahead and check things out for you. You need not do all of the work.

Send me a PM with your address and I will drop one in the mail. Do you want headers soldered in?

Regards,
George Albercook
----------------------------
www.FlutterBot.com

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

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

Oops... I guess that, the fact that my machine is logged in, does not necessarily mean that I am also in front of its monitor! Anyway!

Lee, it seems that I am not able anymore to convince anybody, that I have not been trying to!

Smiley, thank you. I started this project out of my curiosity mainly, being unable to understand what could be going wrong with those Butterflies. In order to do so, somebody needs to be able to reproduce the error.
When I realized that I had already been halfways, I simply decided to finish and release the new bootloader! If you take the time to read the source code you will see that its behaviour is totally predictable, with no surprises at all. A couple of the lock-up reasons I have thought of, might be the oscillator calibration routine, that never ends if a suitable OSCCAL value cannot be found, or a poor Vcc line decoupling, which can also affect the oscillators.

Retro, are you sure that we, the bit-diddlers, are expelled from the joy of the game because we do not have our own playground?
I do not think so. On the contrary, it is widely known that where the C stalls, the assembly takes over*!

(*) Lee, THIS is a flame! A real Casus belli! Anyway, i am just kidding.

George, thank you! I really appreciate your offer and I like this attitude, too. I have not yet purchased a Butterfly unit because I have not felt that it could be of any real use to me, that playing around.
This does not mean that I will not support this little program I wrote in my spare time! The joy of sharing it with the community, has already been all mine! This is my reward! Finally, I think that the Butterflies are not at all expensive nor hard to be found, if I will eventually need to get one! I would not want to be thought as an ungrateful person, though. Thanks, again.

Regards,
George Kolovos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

A couple (out of many :-) ) of questions regarding the code :

Why are the interrupt vectors moved to the boot section ?
And, why is PCINT1 enabled ?? There's just a single, lonely 'reti' at the vector location ??

It would probably make perfect sense if I'd have a Butterfly ... but I don't ...

Other than that it's pretty clear ... almost ...

/J

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

Quote:

And, why is PCINT1 enabled ?? There's just a single, lonely 'reti' at the vector location ??

I haven't looked at that code, but I have several apps with similar constructs on pin-change and other interrupt sources. One can use that to wake up a sleeping AVR with a button press or other event. No action may be needed in the ISR, just a way to wakeup if asleep. And the ISR must be there to "catch" the interrupt.

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.

Last Edited: Fri. Mar 3, 2006 - 07:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee :
Thanks !! that's it !

I actually found the 'Boot_Sleep' subroutine ~10 seconds after submitting the previous post ... :oops: ...

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

Yes Jussi, Lee is right.

The Pin Change Interrupt is only used to wake the CPU up from the Power-Save sleep, which is one of the deepest sleep modes, where everything is frozen to keep the power consumption as low.as possible. Then, the firmware takes over to see what has been happened and how to respond.

As you can see, at the entry point of the bootloader there is a software switch that checks the joystick, and controls the program flow: (1) to start the application, (2) to start the bootloader, or (3) to fall asleep to preserve the battery.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Hello Giorgos,

The mega162 happens to be device I am currently wanting to put a bootloader into.
Any chance you could post the source for your m162 "test" version?

Thanks!
Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Hello Tom,

This "internal release, modified for the m162 chip" of mine, is nothing more that a copy-and-paste of the released program, with a few minor corrections, in order to be able to be assembled for the different target MCU.

I think that it would be better to provide a generic walkthrough, for porting the code to a different target.

Just follow the steps below:
* Open the AVRStudio v4.12, or newer. Create a new assembler project, and set as Entry File a copy of the .asm code.
* Change the ".include" directive, from "m169def.inc" to "m162def.inc".
* Assemble the file and let the AVRStudio show you which register/bit labels need to be changed, because they do not exist at the new target chip. Keep on replacing the invalid m169 registers and re-assembling, until all the invalid definitions have been replaced with the target chip ones, eg. TIFR/(TIFR1,TIFR2).
* Replace all the lds/sts instructions with the in/out ones.
* Re-assemble the file, and restore any invalid in/out instruction.
* You are done, when the AVRStudio successfully assembles your file!
* Search for any possible relative branches without a label (eg. rjmp PC±a) and verify that they still point to the original target point, since the lds/sts instructions occupy more program space than the in/out ones.

Regards,
George.

PS. Tom, please PM me if you still need this particular file.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

It works great! Basically did those patches last night, but system would jump
straight into the application on powerup instead of waiting for a button push.
I "forgot" my system has RC time constants on the buttons, so a "release-wait"
function had to be inserted before the BootCheck code 8-) Also deleted the
osc. cal stuff since I run on a crystal.

Thanks a bunch!
Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

You are welcome, Tom.
Now it is my turn to thank you, for the verification of my code functionality!

George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
;-------------------------------------------------------------------------------
COM_Rx:			; Get USART input to tmp1
;-------------------------------------------------------------------------------

        sbis UCSR0A,RXC ; wait until rx buffer full
        rjmp COM_Rx        ;
        in   tmp1,UDR0      ; get the byte
        ret
	
;-------------------------------------------------------------------------------
COM_Tx:			; Sent tmp1 to USART line 
;-------------------------------------------------------------------------------

        sbis UCSR0A,UDRE ; wait until tx buffer empty
        rjmp COM_Tx
        out  UDR0,tmp1        ; send the byte
        ret

I made these slight changes, mainly so the tx routine would not wait until
last bit sent before loading next byte. (not that it really seems to matter)

Works fine with Avrprog, but I'm having problems getting Avrdude to talk
to the bootloader properly. Seems to be some "device code" conflict, but when
I patch Avrdude's m169 config data with device "79" instead of the existing "75"
It will go through the motions of programming, but the verify fails. Have you tried
using Avrdude?

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

At single-byte com-talk, your configuration could be slightly faster. Though it should not be a problem, I prefer not to have any other activity during the spm CPU freeze time periods. That's why I am waiting for the transmission to finish.

As for the Avrdude, I do not know because I have not used it. Why does it fail at the verification phase? Does it support the block-mode? Does it time-out? Does it consider the bootloader space empty (== 0xFFFF's), which is not? What are the Avrdude configuration settings?

As far as I know, there is no device-code for the m162, because it is not supported by the AVRProg.exe. Have you updated the "PartSign" definition? The ATmega162 signature is 0x1E9404.

There is the Portmon, an excellent freeware com-port sniffer, to help you debug the com-talk, at www.sysinternals.com

George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Quote:
avrdude -p atmega169 -P com1 -c butterfly -v -v -U flash:w:znw.hex -U eeprom:w:znw.eep

avrdude: Version 5.1
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

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

Using Port : com1
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
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 512 4 0 9000 9000 0xff 0xff
flash 65 6 128 0 yes 16384 128 128 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 2000 2000 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00

Programmer Type : avr910
Description : Atmel Butterfly Development Board

Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
Software Version = 1.5; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
Device code: 0x79

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9405
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "znw.hex"
avrdude: input file znw.hex auto detected as Intel Hex
avrdude: writing flash (7180 bytes):

Writing | ################################################## | 100% 4.52s

avrdude: 7180 bytes of flash written
avrdude: verifying flash memory against znw.hex:
avrdude: load data flash data from input file znw.hex:
avrdude: input file znw.hex auto detected as Intel Hex
avrdude: input file znw.hex contains 7180 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.11s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude: verification error; content mismatch

avrdude done. Thank you.

make: *** [program] Error 1

> Process Exit Code: 2
> Time Taken: 00:10

Here are the messages from Avrdude. I set the bootloader device code and signature so that
(I think) it pretends to be a m169. The flash gets programmed with zeros instead of actual
program data. Avrdude accepts both "butterfly" and "avr109" as programmer type, and the
results are the same either way.

Puzzling 8-)

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Speculating, it seems to me that FLASH writing does not start properly after the chip erase cycle, because the latter needs more time to be done, than the single chip erase command does.

Give it another try, raising the chip_erase_delay value to 20000us, for the chip you are declaring to Avrdude as target, at the WinAVR\bin\avrdude.conf file.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Same results. What gets written to the flash is 512 bytes of 0x00.

I guess at this point, I'm curious if anyone has actually used Avrdude to load a program
through this type of bootloader. 8-) A search of the forum did not seem to reveal that
particular activity.

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

I am not sure if I can be of any more help here. I do not have a Butterfly unit, in order to try to update its application firmware though its original preloaded bootloader, using the Avrdude.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

Last Edited: Sun. Mar 5, 2006 - 10:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the help Giorgos, I think I shall post the question in a new thread.

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Tom, I can confirm the misbehaviour of the ButterflyBoot v1.0.asm.

I have reconstructed the m162 test board to retest the bootloader:
Although it works fine using the AVRProg front-end, when I use the Avrdude to command the bootloader, the latter has exactly the same behaviour you have discribed.

I am currently working on it, to find out why it is not compatible with the Avrdude and I will get back with the results.

I apologize for any inconvenience caused,
George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

OK, it is fixed!

That was an easy one: I had to add an Address Reset at the end of the Chip Erase function, and to fix one of my countless typos..

Please, download the updated files (ButterflyBoot v1.1) from the first page: http://www.avrfreaks.net/index.p...

Hoping that the debugging is over,
George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Nice work George, thanks for sharing this!

Mike H.

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

Well....I give it another A+. I've been programming with just the battery in the Butterfly for the past few days and no problems yet...and I'm still using the first version. :)


My AVR Site

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

Giorgos, *You Da Man!*

Excellent work, we are rockin' and rollin' now!

Thank you for launching me into bootloading, something I had avoided
and I was running out of excuses 8-)

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Thank you Mike, and you are welcome!

Thank you LCD, one of my official beta testers ;)
Keep in mind though, that when the bootloader is active the Butterfly consumes huge amounts of the battery energy. That's because the CPU clock is running at 2MHz, instead of the 1MHz when the application runs. Additionally the bootloader does not use the sleep modes to reduce the power consumption.
That is the reason I have kept the USART speed at 19.2Kbps, though I could easily raise it to 38.4Kbps at 4MHz CPU clock, or even to 115.2Kbps at 8MHz, respectively, raising the power consumption even more...

Thank you, Tom! In my humble opinion the bootloader itself is nothing more than yet another piece of software, that can also be full or free of bugs...

George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Hey, you bold AVR Freaks!

Why don't you give the "ButterflyBoot v1.1L" updated firmware a try? 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 below the 512 Words barrier, and fits into the third bootstart position at the address 0x1E00!

Download the "ButterflyBoot v1.1L.hex" from the first page: http://www.avrfreaks.net/index.p...

Please, come back with the results,
George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

Pages