0x940c in AVRProg error message - bootloader confusion?

Go To Last Post
192 posts / 0 new

Pages

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

Pages