0x940c in AVRProg error message - bootloader confusion?

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

There have been a few threads going back to 2001 where an AVRProg error says that at such and such address it expected 0x940c but got so and so. The number ox940c just happens to be the number at the first address location of the bootloader, but these folks aren't trying to download the bootloader. This pops up in the Butterfly a lot, but other threads have it on the ATmega16 and 32.

One definite cause is trying to download code larger than the space available so AVRProg attempts to write to the bootloader section which doesn't happen and when it goes to verfiy the write it sees that 0x940c where it expected whatever it was trying to write there.

But there are some folks who are getting this error when they are writing small programs which makes me suspect --
1. They have set something so that the AVRProg thinks it's got a larger program and trys to overwrite the boot section.
2. They have done something that makes their small program very large so the AVRProg is doing what it is told.
3. They have set something that tells AVRProg to alias the code start section of 0x0000 to the bootloader start section address of ?0x1c00? (I don't remember that address)

So they could be setting something wrong in the makefile or they could be setting something wrong in the compiler setup or it could be something simple that we are all missing.

Any other possibilities?
Any ideas of avenues to explore?

Woof...
Smiley

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

Quote:
The number ox940c just happens to be the number at the first address location of the bootloader

...For what AVR?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

In this case I think he is talking about the butterfly

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

dwh3 wrote:
In this case I think he is talking about the butterfly

Oh, sorry... but this 0x940C seems familiar somehow...
I don't recall very well where I have seen this hex number... maybe @ATmega64/128... first word in the flash.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Urmm... like I say in the first paragraph, searching the forum shows this magic number for the Butterfly, the Atmega16 and 32.

Smiley

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

groenhen wrote:
Quote:
The number ox940c just happens to be the number at the first address location of the bootloader

...For what AVR?

Probably for all of them with a JMP instruction (if JMP is used as the instruction at the interrupt vector). Example:

         ;INTERRUPT VECTORS
000000 940c 03da 	JMP  __RESET
000002 940c 0000 	JMP  0x00

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

Quote:
Probably for all of them with a JMP instruction (if JMP is used as the instruction at the interrupt vector).

Yep... correct, if JMP...
But, there are at least two other possibilities:
Here's one (with RJMP):

         ;INTERRUPT VECTORS
000000 c065      	RJMP __RESET
000001 cffe      	RJMP 0x00 

And the second possibility is... :?:
[s#it... I don't recall now... sorry]

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

>>Typically<<, vector tables (especially compiler generated) will tend to have a series of JMP instructions on AVRs with more than 8kb of flash, and RJMP in AVRs with 8kb of flash or less. When writing your own programs you are, of course, free to put whatever instruction you please at any loaction.

Smiley's point (and it sounds like a good one) is that the reported failures may well have something to do with trying to overwrite the bootloader's vector table.

So the answer to your question "for what AVR?" remains the same:

Quote:

...all of them with a JMP instruction (if JMP is used as the instruction at the interrupt vector).

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

theusch wrote:
>>Typically<<, vector tables (especially compiler generated) will tend to have a series of JMP instructions on AVRs with more than 8kb of flash, and RJMP in AVRs with 8kb of flash or less. When writing your own programs you are, of course, free to put whatever instruction you please at any loaction.

Not quite, as there is one limitation. AVR's with less than 8kb of flash have a vector table that has only one word reserved for each entry (rjmp is the only real option here), while those with more than 8kb have 2 words per entry (thus allowing for jmp, instead of rjmp). Technically one could use RJMP here as well, as long as they remember to skip the unused word, or fill it with a NOP.

As for >>ANY<< code, technically one could place normal code in the unused areas of the table as well, but this is not an advisable practise.

groenhen wrote:
Quote:
Probably for all of them with a JMP instruction (if JMP is used as the instruction at the interrupt vector).

Yep... correct, if JMP...
But, there are at least two other possibilities:
Here's one (with RJMP):

         ;INTERRUPT VECTORS
000000 c065      	RJMP __RESET
000001 cffe      	RJMP 0x00 

And the second possibility is... :?:
[s#it... I don't recall now... sorry]

You're probably thinking of IJMP as the 3rd option. Use of IJMP in an interrupt vector table is not advisable, as it relies on the contents of the Z register being correct.

CALL, RCALL, and ICALL are not good options, because they would require a 2nd return, so DO NOT use these in your vector table. Though they may be viable options in a software vector table, but I doubt it.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Fri. Jun 24, 2005 - 07:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Smiley's point (and it sounds like a good one) is that the reported failures may well have something to do with trying to overwrite the bootloader's vector table.

1) Maybe the application is too large to fit in the app. section...
2) Maybe they have instructed the compiler to put some functions in the BL space. (I do have a project where one function is located in the BL section).

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Hi glitch!

Quote:
You're probably thinking of IJMP as the 3rd option. Use of IJMP in an interrupt vector table is not advisable, as it relies on the contents of the Z register being correct.

Hehe, I did recall... I wasn't thinking of IJMP...
I was thinking of using RETI.

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

Quote:
Though they may be viable options in a software vector table, but I doubt it.

IV hijacking?... or what?

Real men don't use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

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

groenhen wrote:
Hi glitch!
Quote:
You're probably thinking of IJMP as the 3rd option. Use of IJMP in an interrupt vector table is not advisable, as it relies on the contents of the Z register being correct.

Hehe, I did recall... I wasn't thinking of IJMP...
I was thinking of using RETI.

RETI will simply return you to the interrupted code without doing anything... this may not be a bad approach for unused vectors. Though it can still be dangerous, as you can get stuck in an infinite loop of INTERRUPT/RETI's if the particular interrupt that was accidentally enabled is level triggered. I will quite often flesh out all interrupt handlers, even the ones I don't plan on using, and have them disable their interrupt source if they ever get called. During debugging I will also have them log the misfire, so I can try to track down the source of the error.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Fri. Jun 24, 2005 - 07:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

groenhen wrote:
Quote:
Though they may be viable options in a software vector table, but I doubt it.

IV hijacking?... or what?

No, this would allow for multiple entries to be called in sequence, if needed, since the return value will be the next vector entry. Think of a switch/case where for one value you perform one action, and want it to also be processed for the next entry as well. (ie no break statement at the end of the case) This is about the only possible use I can think of, and there are better ways of doing it. You cannot hijack an interrupt vector on an AVR, since the vector table is in flash, and not ram, so you cannot dynamically change the vector. (with the exception of using IJMP, but, as above, this has it's dangers)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Back to the topic: what would be ways that a relative newbie doing what seem to be normal things like compiling and loading very simple programs could cause the error? I've seen several newbies get this error, have hacking fits and nearly quit then the problem goes away. They don't know what caused it nor what fixed it and neither do I. I'm guessing they are making an easy to make mistake, then floundering around until they try something different that works, then they don't do the 'easy mistake' any more. Then another newbie gets impaled by the same thing and I don't know what to tell them.

Smiley

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

I am one of the newbies and I agree with Smiley. Is there anything that a newbie can do to avoide writing in the bootloader's address. Or is there any way a newbie can check his or her source program for that error. Is that error from the compiler or from something in the flash of the butterfly ATmega169 ?

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

This error message has nothing to do with the bootloader. Your butterfly has a lock on the application data. You try to program it, you think you did, and when it verifies it says error. It never programmed it thats why the verification failed. What your going to need to do is program the butterfly with the ISP interface, erase the device and make sure under lock bits there is no locks anywhere. Then you will need to reflash the device with the hex from atmel and your good to go.

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

I have about 50 students and I think maybe 20 of them had this problem. The problem showed up after a few weeks of programming.

I agree with BillH308, but the main question is: why does the lockbit change during programming via the bootloader?

Is there a flash security function, is it the voltage level, or is it the RC oscillator or what?
/Magnus

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

okay, now i'm really scared. We are beginning to get this problem well characterized and it still seems a mystery. Either the AvrProg is doing something, or the bootloader is doing something, or a downloaded program is doing something, or -- the worse case -- something wierd is happening inside the AVR that causes this with no particular external influence.

I've submitted a question to the AVR technical folks and gotten no response. Either they don't know, don't care, or are hiding something.

If the bootloader is capable of spontaneously locking up and one needs an ISP to reset it, then the main reason I moved to AVR is gone and I have to rethink everything.

I hope we can get someone at Atmel to respond.

[EDIT 8/17/05] There is a guy at Atmel trying to replicate the problem. He says that there is not a known bug of having the lockbits set themselves. Stay tuned.

Smiley

Last Edited: Wed. Aug 17, 2005 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi.
I have similiar problem (getting message like this: Adress 0x0000, Expected 0x940c, received 0xffff). I'm using following code for bootloader (from DN032, slightly changed to work with Mega16):

;********** B O O T L O A D E R F O R A T m e g a 1 6 3 **********
;* File : AVRBoot2.asm (Include chip erase counter)
;* Version : 1.2
;* Compiler : AVR Studio
;* Target : ATmega163
;* Output size : 392 bytes

.equ DT = 0x75 ;Device Type = 0x66 (ATmega163)

;.equ DT = 0x82 ;STK500
;.equ DT = 0x74 ;AVR910

.equ SB1 = 0x1E ;Signature byte 1
.equ SB2 = 0x94 ;Signature byte 2
.equ SB3 = 0x03 ;Signature byte 3
;.equ UBR = 23 ;Baud rate = 19.200 bps with fCK = 7.3728 MHz
.equ UBR = 51 ;Baud rate = 19.200 bps with fCK = 16 MHz
;.equ UBR = 103 ;Baud rate = 9.600 bps with fCK = 16 MHz
.INCLUDE "m16def.inc" ;Include Register/Bit Definitions for the mega163

.org SECONDBOOTSTART ;($1F00) second boot. Block size is 512B

ldi R24,0xff ;zapisz do portu A 0xff - wlaczenie pull-up
out PORTA,R24

;sbic PINA,PINA0 ;Skip next instruction if PINC0 cleared
;sbic PINC,PINC0 ;Skip next instruction if PINC0 cleared

in R24,PINA
cpi R24,0x00
breq SKIP
rjmp FLASHEND+1 ;else normal execution from Reset (FLASHEND+1 = Address 0000)

; Programming mode
SKIP:
ldi R24,low(RAMEND)
ldi R25,high(RAMEND)
out SPL,R24
out SPH,R25 ;SP = RAMEND
ldi R24,UBR ;Baud rate = 19.200 bps
out UBRRL,R24
ldi R24,(1<<RXEN)|(1<<TXEN)
out UCSRB,R24 ;Enable receiver & transmitter, 8-bit mode

;-------------------------------------------------------------------------------
;L10
;-------------------------------------------------------------------------------
L10: rcall uartGet ;repeat (R16 = uartGet)
cpi R16,27 ;while (R16 == ESCAPE)
breq L10
cpi R16, 'a' ;if(R16=='a') 'a' = Autoincrement?
brne L12
ldi R16,'Y' ;Yes, autoincrement is quicker
rjmp L70 ;uartSend(R16)
;-------------------------------------------------------------------------------
;L12
;-------------------------------------------------------------------------------
L12: cpi R16,'A' ;else if(R16=='A') write address
brne L14
rcall uartGet
mov R27,R16 ;R27 = address high byte
rcall uartGet
mov R26,R16 ;R26 = address low byte
lsl R26 ;address=address<<1
rol R27 ;convert from byte address to word address
rjmp L68 ;uartSend('\r')

;-------------------------------------------------------------------------------
;L14
;-------------------------------------------------------------------------------
L14: cpi R16,'c' ;else if(R16=='c') write program memory, low byte
brne L16
rcall uartGet
mov R22,R16 ;R22 = data low byte
rjmp L68 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L16
;-------------------------------------------------------------------------------
L16: cpi R16,'C' ;else if(R16=='C') write program memory,high byte
brne L18
rcall uartGet
mov R23,R16 ;R23 = data high byte
movw R30,R26 ;Z pointer = address
movw R0,R22 ;R0&R1 = data
ldi R24,1 ;SPMCR = 0x01
out SPMCR,R24 ;page load (fill temporary buffer)
spm ;Store program memory
adiw R26,2 ;address=address+2
rjmp L68 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L18
;-------------------------------------------------------------------------------
L18: cpi R16,'e' ;else if(R16=='e') Chip erase
brne L28
; for(address=0; address < (2*SECONDBOOTSTART); address += (2*PAGESIZE))
clr R26 ;page_erase();
clr R27
rjmp L24
;-------------------------------------------------------------------------------
;L20
;-------------------------------------------------------------------------------
L20: movw R30,R26 ;Z-pointer = address
ldi R24,3 ;SPMCR = 0x03
out SPMCR,R24 ;page_erase
spm

SPM_WAIT: in R24, SPMCR
sbrc R24,PGERS ;czekaj na wykonanie zapisu
rjmp SPM_WAIT

subi R26,low(-2*PAGESIZE) ;address += (2*PAGESIZE)
sbci R27,high(-2*PAGESIZE)
;adiw R26,2*PAGESIZE
;-------------------------------------------------------------------------------
;L24
;-------------------------------------------------------------------------------
L24: ldi R24,low(2*SECONDBOOTSTART)
ldi R25,high(2*SECONDBOOTSTART)

cp R26,R24 ;address < Boot Flash address(byte address) 0x3E00 ?
cpc R27,R25
brlo L20

ldi R26,low(E2END-1) ;increment Chip Erase Counter located
ldi R27,high(E2END-1) ;at address E2END-1

movw R22,R26 ;Save Chip Erase Counter Address in R22
ldi R17,(1<<EERE) ;read EEPROM
rcall EepromTalk
mov R24,R16 ;R24 = Chip Erase Counter low byte
rcall EepromTalk
mov R25,R16 ;R25 = Chip Erase Counter high byte
adiw R24,1 ;counter ++
out EEDR,R24 ;EEDR = R24 Chip Erase Counter low byte
movw R26,R22 ;R26 = Chip Erase Counter Address
ldi R17,(1<<EEMWE)|(1<<EEWE) ;write EEPROM
rcall EepromTalk
out EEDR,R25 ;EEDR = R25 Chip Erase Counter high byte
rcall EepromTalk

rjmp L68 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L28
;-------------------------------------------------------------------------------
L28: cpi R16,'m' ;else if(R16== 'm') Write page
brne L34
movw R30,R26 ;Z-pointer = address
ldi R24,5 ;SPMCR = 0x05 Write page
out SPMCR,R24
spm ;Store program memory
SPM_WAIT_1: in R24, SPMCR ;
sbrc R24,PGERS ;czekaj na wykonanie zapisu!!!!!!!!!
rjmp SPM_WAIT_1 ;
;-------------------------------------------------------------------------------
;L32
;-------------------------------------------------------------------------------
L32: rjmp L68 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L34
;-------------------------------------------------------------------------------
L34:
cpi R16,'P' ;else if(R16=='P') Enter programming mode
breq L32 ;uartSend('\r')
;rjmp RESET

cpi R16,'L' ;else if(R16=='L') Leave programming mode
breq L32 ;uartSend('\r')

cpi R16,'p' ;else if (R16=='p') Return programmer type
brne L38

ldi R16,'S' ;uartSend('S') Serial
rjmp L70 ;uartSend(R16)
;-------------------------------------------------------------------------------
;L38
;-------------------------------------------------------------------------------
L38: cpi R16,'R' ;else if(R16=='R') Read program memory
brne L40

movw ZL,R26 ;Z-pointer <= address

;ldi R30,0
;ldi R31,0

ldi R24,0xff
out DDRB,R24
out PORTB,R30

lpm R24,Z+ ;read program memory LSB; store LSB in R24 and Z pointer ++
lpm R16,Z+ ;read program memory MSB; store MSB in R16 and Z pointer ++

movw R26,ZL ;address += 2
rcall uartSend ;uartSend(R16) MSB
;movw R26,30 ;address += 2
mov R16,R24 ;LSB stored in R16
rjmp L70 ;uartSend(R16) LSB

;-------------------------------------------------------------------------------
;L40
;-------------------------------------------------------------------------------
L40: cpi R16,'D' ;else if (R16=='D') Write data to EEPROM
brne L42
rcall uartGet
out EEDR,R16 ;EEDR = uartGet()
ldi R17,6 ;write EEPROM
rcall EepromTalk
rjmp L68 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L42
;-------------------------------------------------------------------------------
L42: cpi R16,'d' ;else if (R16=='d') Read data from EEPROM
brne L44
ldi R17,1 ;read EEPROM
rcall EepromTalk ;R16 = EEPROM data
rjmp L70 ;uartSend(R16)
L44: cpi R16,'F' ;else if(R16=='F') Read fuse bits
brne L46
clr R30 ;Z-pointer = 0000
rjmp L50 ;rcall readFuseAndLock
;-------------------------------------------------------------------------------
;L46
;-------------------------------------------------------------------------------
L46: cpi R16,'r' ;else if(R16=='r') Read lock bits
brne L48
ldi R30,1 ;Z pointer = 0001
rjmp L50 ;rcall readFuseAndLock
;-------------------------------------------------------------------------------
;L48
;-------------------------------------------------------------------------------
L48: cpi R16,'N' ;else if(R16=='N') Read high fuse bits
brne L52
ldi R30,3 ;Z-pointer = 0003
;-------------------------------------------------------------------------------
;L50
;-------------------------------------------------------------------------------
L50: rcall readFuseAndLock
rjmp L70 ;uartSend(R16)
L52: cpi R16,'t' ;else if(R16=='t') Return supported devices code
brne L54
ldi R16,DT ;Device Type
rcall uartSend ;uartSend(DT) send Device Type
clr R16
rjmp L70 ;uartSend(0)
;-------------------------------------------------------------------------------
;L54
;-------------------------------------------------------------------------------
L54: ;else if ((R16=='l')||(R16=='x')||(R16=='y')||(R16=='T'))
cpi R16,'l' ;'l' = Write Boot Loader lockbits
breq L56
cpi R16,'x' ;'x' = Set LED
breq L56
cpi R16,'y' ;'y' = Clear LED
breq L56
cpi R16,'T' ;'T' = Select device type
brne L60
;-------------------------------------------------------------------------------
;L56
;-------------------------------------------------------------------------------
L56: rcall uartGet ;R16 = uartGet()
;YOU CAN INSERT LEDs CODE HERE
rjmp L68 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L60
;-------------------------------------------------------------------------------
L60: cpi R16,'S' ;else if (R16=='S') Return software identifier
brne L62
ldi R30,low(2*Soft_Id)
ldi R31,high(2*Soft_Id)
;-------------------------------------------------------------------------------
;L61
;-------------------------------------------------------------------------------
L61: lpm R16,Z+
tst R16
breq L72 ;branch is end of string ((Z) == 0)
rcall uartSend ;else send char
rjmp L61
;-------------------------------------------------------------------------------
;L62
;-------------------------------------------------------------------------------
L62: cpi R16,'V' ;else if (R16=='V') Return Software Version
brne L64
ldi R16,'1' ;uartSend('1')
rcall uartSend
ldi R16,'0' ;uartSend('2')
rjmp L70 ;uartSend(R16)
;-------------------------------------------------------------------------------
;L64
;-------------------------------------------------------------------------------
L64: cpi R16,'s' ;else if (R16=='s') Return Signature Byte
brne L66
ldi R16,SB1 ;uartSend(SB1) Signature Byte 1
rcall uartSend
ldi R16,SB2 ;uartSend(SB2) Signature Byte 2
rcall uartSend
ldi R16,SB3 ;uartSend(SB3) Signature Byte 3
rjmp L70 ;uartSend(R16)
;-------------------------------------------------------------------------------
;L66
;-------------------------------------------------------------------------------
L66: ldi R16,'?' ;else uartSend('?')
rjmp L70 ;uartSend(R16)
;-------------------------------------------------------------------------------
;L68
;-------------------------------------------------------------------------------
L68: ldi R16,13 ;uartSend('\r')
;-------------------------------------------------------------------------------
;L70
;-------------------------------------------------------------------------------
L70: rcall uartSend ; uartSend(R16)
;-------------------------------------------------------------------------------
;L72
;-------------------------------------------------------------------------------
L72: rjmp L10
;-------------------------------------------------------------------------------
;readFuseAndLock
;-------------------------------------------------------------------------------
readFuseAndLock:
clr R31 ;Z pointer high byte = 0
ldi R24,9 ;SPMCR = 0x09
out SPMCR,R24 ;read fuse and lock
lpm R16,Z ;read program memory
ret
;-------------------------------------------------------------------------------
;EepromTalk
;-------------------------------------------------------------------------------
EepromTalk: ;if R17 == 6 then Write, if R17 == 1 then Read
out EEARL,R26 ;EEARL = address low
out EEARH,R27 ;EEARH = address high
adiw R26,1 ;address++

sbrc R17,(1<<EERE) ;skip if R17 == 1 (read Eeprom)
sbi EECR,EEMWE ;EEMWE = 1 (write Eeprom)
out EECR,R17 ;EECR = R17 (6 write, 1 read)
E2_WAIT: sbic EECR,EEWE ;wait until EEWE == 0
rjmp E2_WAIT
in R16,EEDR ;R16 = EEDR
ret
;-------------------------------------------------------------------------------
;uartSend
;-------------------------------------------------------------------------------
uartSend: ; send R16
sbis UCSRA,UDRE ;wait for empty transmit buffer (until UDRE==1)
rjmp uartSend
out UDR,R16 ;UDR = R16, start transmission
uart_wait:
sbis UCSRA,TXC
rjmp uart_wait
ret
;-------------------------------------------------------------------------------
;uartGet
;-------------------------------------------------------------------------------
uartGet:
sbis UCSRA,RXC ;wait for incoming data (until RXC==1)
rjmp uartGet
in R16,UDR ;return received data in R16
ret
;-------------------------------------------------------------------------------
;Soft_id
;-------------------------------------------------------------------------------
Soft_Id: .DB "AVRBOOT", 0
; END of BOOT LOADER PROGRAM

When uploading program to the processor, everything seems ok. When avrprog tries to verify the program, I get message I wrote earlier. The stange thing is, when I reset processor, verify is correct. When using terminal to see what is transmitted from uC, I discovered, that after programing using avrprog, command used to read memory ('R') returns 0xff all the time. I'm quite sure, that the problem lies in manipulating Z-pointer and R27:R26 pair (used for holding adress). I tried to force Z-pointer to point 0x0000. It still give wrong reading (comparing to memory downloaded using PonyProg). By the way, application code that is uploaded thru boot loader begins with 0x940c. Please help.

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

Did you do as DN032 said and program the fuse bits and then the lockbits as it says

Quote:
The Boot Loader has been written for an ATmega163 with 7.3728 MHz clock. The first
time you must program the Boot Loader code into the AVR Boot Flash Section using an
external programmer. Next times, the Boot Loader enables Flash and EEPROM programming
via de UART with a PC running the AVRProg programming software.

To avoid the user can unadvisedly protect the Application Flash Section from software
updates, the Boot Loader supports neither Fuse bits nor Lock bits programming.

After programming a new ATmega163 with this Boot Loader you must program Fuse
and Lock bits as follows:
• The ATmega163 Fuse High bits must be programmed to 0x04 in order to configure
the Boot size to 256 words and to move the Reset Vector to word address 0x1f00.
• The Lock bits must be programmed to 0xEF to protect the Boot Flash Section from
unintentional changes and to allow accessing the Application Flash Section.
• The Fuse bits must be programmed before programming the Lock bits.

Please note that this is a copy and paste quote and though I am know for my typos, I did not say "via de UART".

Also, can anybody tell me what the second paragraph means? Is this Norwegian translated by Babelfish?

Smiley

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

Thank You for attention, but this wasn't the problem. I figure out that problem involves RWW section read permition. After programing device, reading of RWW section was disabled. All I need to do is to add following lines:

;-------------------------------------------------------------------------------
;L38
;-------------------------------------------------------------------------------
L38: cpi R16,'R' ;else if(R16=='R') Read program memory
brne L40

movw ZL,R26 ;Z-pointer <= address


ldi R24,(1<<RWWSRE)|(1<<SPMEN)
out SPMCR,R24
spm

which reenables reading RWW section. With this code everything works just fine (maybe there is more efficient way to do this - with code above, red lines are executed each time R command is issued).

Best regards.
-=lutecki=-

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

Another newby with this error...

Since the posts are very recent on this matter, should I assume I won't find a solution to this problem elsewhere in the forums? I too am getting this error "Address 0x0000, Expected: 0x940c, Received 0x0100" when using AVRprog with the Butterfly. I'm new to this and have been practicing and loading small programs to the Butterfly for a couple of days with no problems. All of a sudden, I am getting this error. I've gone back, double and triple checked that I'm not doing anything different, but no success. I've tried loading programs that originally worked fine and get the same result.

Don't know if this is related but......Before the first time this showed up, I was seeming to have a communication error over my serial connection and got the error "No supported board found! AVRprog version 1.37" I eventually got it working after trying several things so I don't know what the problem was. The subject problem started the first time I attempted to load a new program.

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

Yeah... the problem goes on. Atmel has a fellow in Norway looking into this, but so far he can't replicate the problem. The only solution I know is to reprogram the Butterfly via the ISP port. You can get an ISP programmer for about $30 bucks. If you are long term serious and commited to the AVR just go ahead and buy a STK500 $90 an you are in business, but if you are just dabbling you might consider getting another Butterfly until we figure this out.

Sorry,
Smiley

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

Butteryfly back in business.......I'm back in business. I went ahead and purchased the STK500 since I was planning on getting it eventually anyway. I just programmed the "butterfly_app_rev06_and_boot_rev03.hex" file into it from Atmel's site and the lock bits are back to normal and the butterfly is operational.

Thank goodness there is such a wealth of information to be found in these forums. Thanks all.

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

The question that is still freaking me out is how the %#^%*#*&!! the lock bits get set in the first place. Yeah, we can fix it with an ISP programmer, but that kind of defeats the purpose of a $19.99 board doesn't it? I guess adding a $29.99 AVRISP still provides a cheap learning enviornment at 49.98, BUT, something weird is going on and who wants to use a product with weirdness built in? I guess if this was a problem with the AVR itself we would have heard about it long ago, but still, I worry.

Smiley

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

lutecki wrote:
I figure out that problem involves RWW section read permition. After programing device, reading of RWW section was disabled.

The problem lies in SPMCR's handling in general. You have done some serious mistakes regarding that. You need to read carefully the ATmega16 datasheet, the part about the bootloader support.

You don't follow the right steps. For example, you check for PGERS instead of SPMEN and RWW section is not treated right.
There are code examples and algorithms that will help you fix your code.

----------------------------

As for the rest of you guys, with the butterfly problem, here is my thought:

the AVRProg command for writing lock bits is ASCII 'l'=$6C=0b01101100 and since I don't own the butterfly, I took the hard way to reassemble the boot.hex file, to find out that the 'l' command is fully supported which means that when an 'l' arrives, the mega169 stores the next incoming byte to the Lock bits without asking for anything else(nor looking for framing or ather UART errors). The AVRProg (AVR910) protocol doesn't support CRC or other checking.
The 0b01101100 number seems to me an easy number to misread when a contact is loosy, don't you think?
Further more, the protocol is so simple that if the communication is lost for some reason(could be buggy bootloader like the one posted above) and a byte is lost, the bootloader will be confused and an 'l' may pass through as command, even if it is a data byte.
...You all got the idea.

However, have you really confirmed that when the 0x940C error occurs, the LockBits are set? By reading them using ISP?

You can hack the hex file by yourself and add UART error detection, or even to replace the 'l' functionality with a dummy respond, just to keep the AVRProg happy and your butterfly unlocked.

Then, if the problem happen again, well, ISP it again! :P

P.S.
I don't know if it is legal to post the reassembled asm file, ReAVR is the tool.

Kyriakos

Practice Safe hex.

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

Quote:

...replace the 'l' functionality with a dummy respond, just to keep the AVRProg happy ...

That seems like a good interim solution for a learning device -- make a replacement version of the bootloader which ignores requests to modify the lockbits. If, indeed, the problem really is that the lock bits are being inadventantly set.

In the future, if somebody goes on to produce a commerical device where lockbits are crucial, then they can spring for an AVRISP (or similar) to make sure the lock bits are done right.

But, is there another widely-available bootloader-and-PC-application pair out there which does incorporate CRCs or checksums or some other error-checking in its protocol?

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

You are right about PGERS, but what You mean by "RWW section is not trated right"? I went thru the code once again and IMHO it is consistent with AVR910 protocol, what are my serious mistakes? I'm not fluent in assembler, so any comment will be appreciated. And yes, i read datasheet carefully.

Best regards
-=lutecki=-

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

I hate hijacking other people threads, but I'll be in topic later.

lutecki:
You need to read more :P
The code IS consistent with AVR910(or better, the protocol in AVR109 appnote), but the DN032 and so your code are not consistent with the datasheet. The bootloader might work ok, but is is buggy!

The ATmega163 has some weirdness, unique in the AVR family.
1- He needs

.dw $FFFF
nop

after each Page Erase, Page Write, and Lock-bit Write spm instruction.
2- The RWW bits in SPMCR are not there, but some others( though compatible with the RWW bits in newer AVRs).

Anyway, the DN032 bootloader(for ATmega163) is missing:
1) the $FFFF after the spm
2) some checking for SPMEN and EEWE flags before the spm
3) application section enable after each page erase/write, using ASRE bit
4) optional application busy check(ASB flag) and then application section enable(ASRE bit) when you want to jump and execute code in application area(RWW section).
Note: The first step for the above changes is to replace the simple spm instruction with the do_spm routine, found in the datasheet. That routine's aspect is great. It assures you that the pare erase/write actions are taking place in a right manner and the RWW section is allways accessible with no risks.
The datasheet HAS all the routines you need. RTFM.

Now, for the migration to ATmega16.
The ATmega16 doesn't have the spm/$FFFF/nop silicon bug(according to the datasheet) but you can leave it, just in case. It doesn't harm anything. The steps 2,3,4 are the same, just rename the bits.

I have done the modifications of the DN032 bootloader for various AVRs(ATmega32, ATmega163, ATmega161, ATmega162[fake DT], ATmega128[you should see the mess here with the RAMPZ :P ]) and all work nicely but I used them only in early versions of prototypes.

[in topic]
I haven't done the UART framing error checking in these bootloaders because in my opinion, the AVRProg, the DN032 bootloader and the Butterfly are only tools for us(developers), just to show us how things work and they are not intented for commercial products. On our bench, in our home projects they work ok but that's because we know how they work and we can fix their bugs/faults.

For the development stages of a project with Butterfly you can ommit the LockBit feature, don't you think? I mean, disable it in bootloader, as I said in my first post. Then, when you have the final application code, you can put back the original bootloader and relly on Merphy's law's failure if you still want to sell it as a commercial product.

Second, if you plan to add UART error detection, the only action you are allowed to take, after the error occurs, is to ignore all next incoming chars until the AVRProg goes mad and stops sending chars. Then the user must do a manual RESET and repeat the burning proccess. Else, if you just ignore the faulty char and accept all next chars, an fatal error may occur.

Little story:
When I was modifying the bootloader for the ATmega128, I did a major mistake, I changed the previous string ["AVRB32 ",0] to ["AVRB128 ",0] but that was 8 bytes instead of 7 that the protocol supported, so the AVRProg received back 1 more char and it gone crazy. It kept sending a few commands but all the responds were shifted by 1 byte.
The bug in AVRProg is that they don't flush the UART Rx buffer before Txing a command.
That's IMHO a inoccent bug, but shows that the utility isn't professional, right?

So, my advice is to not use this kind of bootloader in any commercial product but only for our personal needs.

Practice Safe hex.

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

My story goes here:

I have recently bought a Avr Butterfly from smileymicros.com

When trying to program it via AVRprog I got the same error as many ppl in here - 0x940c
Hmm, what to do...
One of my friends had a STK500, which I borrowed to fix my problem.
After reading the "lockbits" - the result was clear. "Application Protection Mode 3: LPM and SPM prohibited" was enabled.
I tried to set it to "Mode 1", but without any luck. Erasing the device was the only option left. After the erasing, I downloaded the Bootloader from atmel at rebooted my butterfly. When reading the lockbits in Avrstudio it was "Mode 1" - perfect.
I then tried with my ordinary UART-connection via RS232. Stop, the same error again - 0x940c.
What the heck - when investigating the case closer, I discovered the lockbits was set to "Mode 3" again. I think this happened when I used the bootloader.
The problem never occurs when using the GCC-ported bootloader, because AVRStudio won't find the butterfly. When connecting from Bray's terminal I get a lot of .............. followed by a sequense of random ascii-characters AFTERWARDS I have tried AVRStudio.
Before using AVRStudio, the result is correct. The screen is filled with ??? :)

I am really lost right now :(

// Jacob Friis

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

Hi everybody

I've been looking at this problem now and I have not been able to provoke the failure with the lockbits. If any of you users can please post a reply in this thread were you explain exactly what you did before facing the programming problem It would make the job of finding the error much easier. I'm looking for Lock bit settings, fuse bits etc..

Best Regards
Andreas Eieland
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 --

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

Andreas,

Have you tried messing with the joystick while the bootloader is downloading code? Seems I got the idea that the bootloader might reset in the midst of a download then interpret incoming data as commands, one of which is to set the lockbits. I also wonder if something intermittent on the RS232 line or the power input (for those using external batteries) could make the bootloader forget what it's doing, and start to interpret data as commands?

Smiley

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

Here are my experiences regarding this problem

Last time when a BF locked it self, I think my finger on the joystick trembled. One other time I had some hardware connected to port B and maybe I that way (by mistake) trigged an interrupt.

When the error occurs it always happens like this:
First I try to download code, the error message from AVRprog “No supported board found” appears. Then when I try to download code again it seams to run fine but then the error Address 0x0000…. shows.

The error happens when I use the bootloader in the hexfile “butterfly_app_rev06_and_boot_rev03.hex” It has never occurred when I use “original_butterfly_application.hex” that can be downloaded with the AVR109 Application Note. But on the other hand I have not used to many of those.

I have students that have used two rechargeable batteries (about 2,4V). They always fail. The BF always locks itself when the voltage is too low.
/Magnus W

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

My butterfly is brand new and I am getting this error. It is definately not the program I am trying to load. My voltage is 2.7V, I will connect a higher source to see if that helps. I do have the stk500 just not certain about how to use the stk500 to program the butterfly. Help would be great...

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

Update...voltage was not the issue.

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

dblessum wrote:
I do have the stk500 just not certain about how to use the stk500 to program the butterfly. Help would be great...

Check the AVR Studio helpfiles --> AVR Tools User's Guide --> AVR Butterfly User's Guide --> Using the AVR Butterfly--> Programming.

The section contains info on both ISP and HVPP programming of the Butterfly using the STK500.

Best Regards
Andreas

--
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 --

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

This just in from dblessum:

Quote:

I got lucky fixed the problem. I had AVR Studio version 4.10, I downloaded version 4.11 and installed service pack 3. This took care of my problem J. Thanks for the help, use this info for future issues…

If anyone else has this problem, then upgrades to 4.11 service pack3 PLEASE report back here as this damn problem is very hard to reproduce and we really need a fix other than reprogramming the Butterfly.

[edit] I missunderstood somebody. THIS WILL NOT FIX THE PROBLEM.

Thanks,
Smiley

Last Edited: Thu. Sep 22, 2005 - 04:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi - I have been in communication with Joe, and at least in my case, I started with the AVR Studio 4.11.410 SP3, worked successfully with the Butterfly over the serial interface for a few weeks, then got into the lock-up state a few days ago.

So while it is still plausible (but unlikely) that upgrading from 4.10 to 4.11 fixes the problem, it appears that simply using 4.11 is not a fix. However, as Joe indicates if anyone corroborates that the upgrade process is the key to unlocking the Butterfly, we'd love to hear about it.

Note that I was using the Butterfly with 2 x 1.2v rechargeable NiMH AAs. If the lockup is voltage related, I may have been pushing the envelope here. (Although it worked great for a few weeks).

-h

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

Hi guys!

On the voltage issue, please note that the voltage operating range for the mega169V placed on the AVR Butterfly is 1,8-5,5V. If your batteries are close to empty (and you have changed the BOD settings) programming of the device might be unsuccessfull leading to unpredictable behavior.

A nice tip is to always remove the battery when not using the device .

Best Regards
Andreas

--
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 --

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

eieland wrote:
Hi guys!

On the voltage issue, please note that the voltage operating range for the mega169V placed on the AVR Butterfly is 1,8-5,5V. If your batteries are close to empty (and you have changed the BOD settings) programming of the device might be unsuccessfull leading to unpredictable behavior.

A nice tip is to always remove the battery when not using the device .

Best Regards
Andreas

Howsomeever, you can reliably get the 0x0940c error by using the bootloader with the Butterfly powered at 2.4 volts. I am now recommending that users make sure that they have at least 3 volts power and do not use weak or rechargable batteries (2 x 1.2v = 2.4v).

Further, I think this problem could be fixed with a new bootloader for the Butterfly that cannot set fuses. Once a user gets advanced enough to know what a fuse is, then that user can download a more advanced bootloader.

Smiley

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

It just took me a few days to reach this state. It happend when I tried to program the butterfly using an external power supply. I didn't solder the connection, so the power could have been instable. Now I know that this is dangerous... Fortunately I know somebody who owns an ISP-programming-unit.
But what surprised me: The damaged bootloader still can send its '????????'-string.

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

The problem seems to be with the new bootloader that comes with the new Butterflies that allows fuses to be set where the older code didn't. So the power goes flaky for a moment and the bootloader goes insane and sets a fuse. Still the only solution is to reprogram the chip. Please use the code port by MJThomas as he uses the older bootloader. His website:

http://www.siwawi.arubi.uni-kl.d...

This new information comes from Gwen's thread at:

http://www.avrfreaks.net/index.p...

Maybe we can get Atmel to revert to the old bootloader?

Good Luck,
Smiley

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

Hello freaks,

One short question, the ones who have observed the problem, are they using AVROSP or AVRPROG?

As you guys know we have tried to recreate this problem without success, I have now also talked to the guy who wrote the bootloader and he told me that he had heard of this problem using AVRPROG, but that he was not able to recreate it either. AFAIK no one has seen this problem using the latest version of the bootloader and AVROSP.

-Andreas

--
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 --

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

Andreas,

I've only used AVRProg in AVRStudio 4.11. Since I sell Butterflies and have someone complain about once a week, would you like for me to have them send you their Butterfly in exchange for a new one? Magnu Wessberg had about 20 students create this error using rechargeable batteries and letting the voltage get below 2.4 V.

Smiley

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

I'm one of the SmileyMicro customers that has just got this problem...

If I understand correctly, what you are all saying is that a design flaw in the bootloader allows a corrupted datastream (possibly caused by a low voltage or hitting the joystick while progamming) to set some lock bits which it cannot then unset. The only way to unset them is via a more expensive programmer using the ISP or JTAG interface.

A suggestion for SmileyMicros - if there is an alternate bootloader that does not have this "feature" it might be worth you reprogramming the butterflies you sell before shipping them, to save on the customer support calls.

I'm now debating whether to invest in a STk500 (what would it give me other than a way to recover my broken butterfly?), try to come up with some other cheap ISP programmer, buy another butterfly, or go back to PIC.....

Richard

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

All is speculation, we don't really know for sure what is going on yet. Most folks are lucky and don't run into this problem. If you plan to get into AVRs seriously, then the $79 STK500 is required. If you just want to do ISP programming the $29 AVRISP will do, and a new Butterfly is $19.99.

I'm personally a bit embarassed by this problem and I think Atmel should be also. I sell the Butterfly mainly to sell the book and the margin is so low that it almost isn't worth the trouble to sell it, considering that I also add a DB9 connector and wire. Contact me at: joe@smileymicros.com and we can discuss other alternatives.

Read a bit more on this site before going back to the PIC, especially the AVR vs. PIC threads. The Butterfly is not the AVR, just a cheap evaluation board for the Atmega169. If you get this problem it is very frustrating. But what does the least expensive comparable PIC solution cost when you consider that the AVR has a free unlimited C compiler, my C programming book, and this forum for support -- do you get a better deal with PIC? If so, I'd like to hear about it.

Smiley

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

I also had the same exact problem with my butterfly.

I still program PICs as well as AVRs...

Do NOT forsake AVRs for PICs!
AVR is just sooo superior.

I advise getting the STK500..it is reasonably priced and
if you are at all serious about working with controllers you
will need this...it's an isp programmer, a hi-voltage programmer
and a development board.

Atmel has the new USB version of the avrisp coming in a few weeks.
It will retail for 34$ and I advise getting it also...I am eager to get mine.

If you want a nice low-cost USB prgrammer right away then get the
new one from ere...it looks very nice. You could use it to rescue
a wayward butterfly..all you would need to do is make up a 10-pin
to 6-pin adapter cable (ere sells cheap cables also)
the ere ISPAVRU1 is 29$ and here is a link to the manual
(PDF) http://www.ere.co.th/download/is...

[img]http://www.ere.co.th/(foebb1fq2iab4njpp4wjgw55)/ProductImages/ISPAVRU1_256x256.jpg[/img]

I think this programer can also provide a clock source for the chip if you
need it.

Quote:
I'm personally a bit embarassed by this problem

Don't sweat it Smiley...how could you have known the butterfly
would turn out a bit flakey.

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

here is the 10 to 6 pin adapter from ere..it is 1.20 ea
[img]http://www.ere.co.th/(foebb1fq2iab4njpp4wjgw55)/ProductImages/I106_256x256.jpg[/img]

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

Ok, I also experienced the problem and toasted 2 brand new Butterflies in 2 days.

No, the problem isn't voltage related.Both happened with brand new 3v button batteries. Also not related to having the latest and greatest AVRProg... I just downloaded mine.

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.

On the second one, after reading this thread, I was a lot more careful. Exact sequence of operation:

1. Connected brand new butterfly with serial cable to a computer with the latest AVRStudio and WinAVR tools installed.
2. Verified computer talks to butterfly using name download.
3. Used butterfly menu to go to the bootloader section, then held button down and started AVRProg. After a short delay the AVRProg popped up its menu, I selected the factory hex file, downloaded ok. (First sucess!)
4. Repeated above with the GCC port, made sure it works by trying new keyclick menu. Success!
5. Made a very slight change to source and recompiled, modified "Butterfly" name so that I can tell what version is running. Downloaded as above, worked fine, unit shows new name.
6. Made 2 other slight changes, 1) commented out call to osc. calibration because AVR studio would get stuck in that routine during simulation and for the moment I don't care about exact calibrations. 2) added a couple calls to UsartTx() to send out a few characters in the menu loop.
7. Tried downloading, AVRProg warned me that program extends into boot section, so I cancelled the download.
8. Now Butterfly won't respond to up-arrow.
9. Restarted AVRProg with button held down, starts as before. Tried downloading factory hex file again, wouldn't take, complained about the 940c.
10. Still no response to up arrow, but will respond to AVRProg, but anything I try will result in same 940c error message.

This was within minutes of using brand new Butterfly with brand new battery, so not a voltage issue. Maybe this will help you debug ?

Separately, I have a total AVR newbie question: How can I tell from the map file whether my modified program extends into the boot section? I only added a couple of function calls, was the code so tightly packed that you have to delete stuff before adding any line of code ?

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

RayKAvr wrote:
This was within minutes of using brand new Butterfly with brand new battery, so not a voltage issue. Maybe this will help you debug ?

Jeez... I don't know what to say other than I hope you have an ISP programmer handy. This is really frustrating. I haven't calculated the exact percent, but I think about 95% of the Butterflies work okay but there seems to be some flaky ones circulating. If you do get an ISP, see if you can download not just Martin Thoma's GCC port of the Butterfly code, but his port of the old bootloader. I'm suspecting the new bootloader as the source of the problem since it allows setting fuse bits. But who knows?

RayKAvr wrote:

Separately, I have a total AVR newbie question: How can I tell from the map file whether my modified program extends into the boot section? I only added a couple of function calls, was the code so tightly packed that you have to delete stuff before adding any line of code ?

I've never looked at this other than glancing at a few AVRFreaks threads and I don't remember the upshot. I do know that the original IAR code filled the Butterfly and they had to remove seveal songs to get it all in.

I would suggest that once you get these reprogrammed you might look at my Quick Start Guide below and start simple with the Blinky program and build from there.

Good Luck,
Smiley

  • 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

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

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!

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

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....

Mike H.

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

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?

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

Retro,

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.

- Dean :twisted:

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

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

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.

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

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.

- Dean :twisted:

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

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

Quote:
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 :)

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

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.

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

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.

- Dean :twisted:

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

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

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?

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

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.

- Dean :twisted:

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

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

Sorry, tried to re-compile your source-code but AVR STudio complains that I need to install something called WinAVR? Can anyone comment?

Thanks again.

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?

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

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.

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

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?

- Dean :twisted:

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

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

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 :?.

- Dean :twisted:

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

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

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.

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

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.

- Dean :twisted:

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

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

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:
ButtLoad/ButtLoad.hex

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.

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

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?

- Dean :twisted:

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

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

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.

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

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!

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

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.

- Dean :twisted:

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

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

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?

Good luck!
Mike H.

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

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.

TTFN

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

RetroDan wrote:

Quote:
...maybe I should just say to heck with it!

Wait!

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

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

[edit] Self Censored [/edit]

Last Edited: Tue. Mar 14, 2006 - 12:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

TTFN

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

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...

- Dean :twisted:

PS: Butterflies *are* a good starting point, apart from that occasional glitch.

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

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

Quote:
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.

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.

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

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.

Regards,
George Albercook
www.FlutterBot.com

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

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

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?

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

Hi Freaks,

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.

Best Regards
Andreas
Atmel AVR Technical support

Attachment(s): 

--
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 --

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

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.

- Dean :twisted:

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

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

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.

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

RetroDan, please allow me a correction.

Quote:
[...]
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)
[...]

My enhanced, assembly crafted Butterfly bootloader is not "probably smaller". It IS smaller: It is only 471 Words long, against the 759 Words long official "butterfly_boot_rev03.hex".

Therefore you can extended the Butterfly Application Section to 7679W (=15358 Bytes) instead of the 7167W (=14334 Bytes), the official bootloader allows you to:

Quote:
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.

Reference: http://www.avrfreaks.net/index.p...

George

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

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

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

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

You are welcome.

LOL! I am open to its name suggestions!

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

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

Well I'm gonna' call it GeoLoad if that's okay with you Giorgos?

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

I've copied Andreas' response over to the condensed version of this thread in the tutorials section:

http://www.avrfreaks.net/index.p...

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.

Smiley

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

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!

Reference: http://www.avrfreaks.net/index.p...

George.

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

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

Great George!

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.

Smiley

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

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!

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Is the assembly listing shown on that page for the latest version of GeoLoad1.1(L)

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

Dan,

Those BF that locked up -- what were the fuses set to when prior to
"unlocking" them? Just curious...

Rusty
Van Alstyne, TX

Rusty Haddock = KD4WLZ = rusty@fe2o3.lonestar.org
**Out yonder in the Van Alstyne (TX) Metropolitan Area**
Microsoft is to software what McDonalds is to gourmet cooking

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

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.

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

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.

- Dean :twisted:

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

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

Thanks Dean, what particular fuses should I be looking at?

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

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".

- Dean :twisted:

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

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

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?

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

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).

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

Thanks Steve, but I was looking for a link to the new BootLoader from ButterFly/AVR Develpment team. They also wrote a new one.

But thank you anyhow for your help.

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

Okay, sorry. I will look around. I remember seeing the announcement from Atmel.

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

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.

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

Okay, thanks Steve, I Just downloaded it.

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

That would be back on the previous page, page 9. Have a look near the very bottom for the post.

- Dean :twisted:

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

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

... or, at the excellent Smiley's Butterfly 0x940C error summing-up, here: http://www.avrfreaks.net/index.p...

Dear RetroDan, the latest release is the "ButterflyBoot v1.1L.hex", which has the Lock-bits writing feature enabled.
There have not been any misbehaviour reports yet...

George.

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

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

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

-------------------------------------------------------------------------------------------------------
AVRISP:
Entering programming mode... OK!
Reading fuses... 0xFF, 0X98, 0xE2... OK!
Leaving programming mode... OK!

LOCKBITS: (These are the ones shown with a check-mark)
[v] Mode 1: No Memory Lock Featured Enabled
[v] Application Protection Mode 3: LPM & SPM prohibited in app sec
[v] Boot Loader Protection Mode 1: No lock on SPM and LPM in Boot Loader
(No other Lockbits show checkmarks)

FUSES:
[v] Brown-out detection disabled
[v] JTAG Interface Enabled (JTAGEN=0)
[v] Boot Flash section size=1024 words @ $1C00
[v] Boot Reset vector Enabled (def addr=$0000)
[v] Int RC Osc; Start Time 6 CK + 65 ms
** In Addition Fuse Marked "Serial Program Downloading (SPI) enabled (SPIEN=0)
is filled-in with grey color and a RED Question mark[?}
(No other Fuses appear to be checked-off)
-----------------------------------------------------------------------------------------------

Which are the problematic Fuses/LockBits?

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

I would imagine:

Quote:
[v] Application Protection Mode 3: LPM & SPM prohibited in app sec

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!

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

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.

Is that inline with everyone's assumptions?

I'm to "burn" GeoLoad Version 1.1(L) from Giorgos Next and test it.

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

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(?)

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

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?

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

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.

I guess that we should continue the debugging at the dedicated enhanced Butterfly bootloader thread: http://www.avrfreaks.net/index.p...

Thanks for the feedback,
George.

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

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

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.

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

If the FLASH-dump has been generated using the bootloader, it is useless bacause a locked FLASH will report pseudo-random memory contents.

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

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

The dump was done using Dean's ButtLoad acting as an AVRISP device connected to the problem ButterFly. Would that HEX dump be of any use?

If not, can I unlock something to get a better HEX Dump?

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

RetroDan,

Have you used an ISP programmer to load the older version of the bootloader from: http://www.siwawi.arubi.uni-kl.d...

And, if you did load that bootloader did the failure give you the 0x940c in the error message?

Smiley

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

Older BootLoader? No Sorry, let me explain...

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.

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

Dan,

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 ?

Cliff

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

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?

Thanks,
Smiley

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

Cliff, been so busy playing around with ButterFlies (they really are cool!) that I just have not got around to setting the STK500 up, but I will.

Smiley, Okay now I understand. Good thinking. I seem to have an unusual situation here so lets make the best of it.

BTW - I have just had a version of Giorgos' GeoLoad 1.1 FAIL on me.
The error is 0x6246 instead of the 0x940c

Just for the sake of clarity, that means that BOTH the Giorgos' BootLoaders have failed.

The 1.1 version AND the 1.1(L) version.

I will next try following the above link and try the older version of the BF/BL next.

TTYL

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

Smiley, I need help.... I see three BootLoaders at that link.

1) ABR ButterFly BootLoader - Code port to avr-gcc
2) AVRPROG (AVR910) compatible BootLoader
3) BootLoader compatible with STK500

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

Geez, there's all sorts of version at that link.

I really want to help if I can. How about you UPLOAD the exact version you want me to test as a HEX file right here and now(?)

That way if it fails there will be no confusion about which one I was actually using.

Sound good?

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

He it is.

If AVRFreaks is still having the download naming problem it may appear as index.php, just rename it bfboot.zip and opent it.

Smiley

Attachment(s): 

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

Okay I just DL'd it.

I have been using the NEW Official BootLoader from AVR and I have been unable to make it "Lock-Up."

I will switch to this "Smiley" Version right now.

BTW - DL Files are renamed index.

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

If the new version works, then we have our solution, no need for further tests.

Smiley

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

Oh Geez, thanks, after I just switched....

Okay, I will revert to the NEWEST version of the OFFICIAL BootLoader.
And continue testing that one.

BTW - So far neither the "Smiley Version" or the Newest Version have failed yet.

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

Hello guys,

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:

---
ARod

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

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!

---
ARod

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

Just my personal opinion... I think for the price you'll probably wish you'd ordered two ButterFlies.

To use an old Retail Term "One to show and one to Go!"
Or if you're more a computer hacker "Always have a Backup!"

If something's not working, you can always determine
if it's a hardware problem by switching one-for-the-other.

Just a thought, for the price of a few burgers.

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

ARod,

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.

Good Luck,
Smiley

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

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...

*** Of all the things I've lost.... I miss my MIND the most! ***

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

Dan, the sequence is:

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!

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

alejmrm wrote:
Hello guys,

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!

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

Here what I tried Dean.

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.

So I hope that are shipping new BFs with this new version.

TTYL

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

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!

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

Okay will do!

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.

Just a thought.

Enjoy your trip!

PS. Still no problems with new AVR ButterFly BootLoad.

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

Dean,

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.

---
ARod

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

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: http://www.avrfreaks.net/index.p...

George.

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

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

Can anyone Confirm if the new ButterFlies are being shipped with the new Bootload software?

BTW - what are they going to do (if anything) about the ones sitting on suppler shelves?

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

CAN WE PLEASE LET THIS THREAD DIE AND DO ALL FURTHER POSTS ON THE 0x040c ISSUE WHERE IT CAN DO SOME GOOD?

PLEASE PUT FUTURE 0x940c ERROR POSTS ON:

http://www.avrfreaks.net/index.p...

SO I CAN CONSOLIDATE THEM INTO A SINGLE USEFUL POST.

FOR POSTS UNRELATED TO THIS ISSUE PRECISE, PLEASE START A NEW THREAD.

Smiley