New xmega Bootloader (App Note AVR1605) - Port to GCC

Go To Last Post
142 posts / 0 new

Pages

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

rajendar.k wrote:

When I said moving the program to boot section,its not through the BOOTLOADER_SECTION way. Explicitly giving the .text section of the program, boot section start address (linker script or through LDFLAGS(section-start) in Makefile).

I never had any luck setting the linker script directly in the makefile when using AVR Studio. I had to use the GUI options for memory locations to link it correctly.

-- Damien

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

Damien,

Quote:
I never had any luck setting the linker script directly in the makefile when using AVR Studio. I had to use the GUI options for memory locations to link it correctly.

I am able to do this in 3 ways(Could confirm this from the .lss file generated along with executable).
(#Link Command in the Makefile that generates final executable)
$(CC) -Tavrxmega.x $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)
and edited this line in the linker script (attached, changed file name to avrxmegal instead of avrxmega.x)
text (rx) : ORIGIN = 0x0, LENGTH = 1024K to
text (rx) : ORIGIN = 0x20000, LENGTH = 1024K
or
LDFLAGS += -Wl,-section-start=.text=0x20000
or
from the memory configuaration option in the AVR Studio,where the memory size is to be given in number of words(0x10000 for 128a1[boot section start address]).

Also, we are using WinAVR-20080610 compiler.Any issues with this for bootloader ?

Regards,
Rajendar

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

Sorry,
I am not able to attach the file.
(I get this error : The Extension is not allowed)
Regards,
Rajendar

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

rajendar.k wrote:

and edited this line in the linker script (attached, changed

You can zip it an post it. I don't mind if it contains all the build artifacts (indeed, the more the merrier)

Quote:

Also, we are using WinAVR-20080610 compiler.Any issues with this for bootloader ?

Do you have an environment where you can test WinAVR-20090313 - it's the only version I have tested with it.

-- Damien

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

Finally some good news.
With the latest compiler WinAvR 20090313, the Uart program starting at boot section works !!!!!!

Regards,
Rajendar

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

Still no success for me :( I checked clock speed, bootloader section location, -e, lock bits etc... I always get an error:

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

with the erase option, I get timeout:

avrdude: Device signature = 0x1e9744
avrdude: erasing chip
avrdude: butterfly_recv(): programmer is not responding

Power is set to 3.3v. Anything could prevent the bootloader to write to flash ?

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

I have found the problem, but not yet fixed. This is a bug of the xmega192A3 (also in xmega256a3 and others).

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

I just got damien_d's port of the AVR1605 note to avr-gcc to work on the bostonandroid.com Xmega64a3 board. Some minor mods for page sizes and num pages. I also modified the avrdude.conf file included in winavr-20090313. It looks like the latest version of AVRDude is already configured for all the xmega chips, but I didn't see a precompiled exe for windows.

-Paul

Attachment(s): 

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

I am surprise that this works for the xmega64A3, or maybe you have a newer version of the chip. In the xmega 256/192/128/64 A3 datasheet, there is an errata saying that "Writing EEPROM or Flash while reading any of them" does not work.
Flash cannot be self programmed without a workaround (see page 96 item6). There is a workaround application note from Atmel support (avr1008.pdf), but it still does not work yet for me.

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

wandererwolf wrote:
I just got damien_d's port of the AVR1605 note to avr-gcc to work on the bostonandroid.com Xmega64a3 board. Some minor mods for page sizes and num pages. I also modified the avrdude.conf file included in winavr-20090313. It looks like the latest version of AVRDude is already configured for all the xmega chips, but I didn't see a precompiled exe for windows.

-Paul

Cool. Thanks. I never expected my dirty hack to be ported to anything else :)

-- Damien

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

Now that I've read the errata I'm surprised it works too! I loaded a simple test program with the bootloader that was only 600bytes but it loaded and verified without error and appeared to be running fine. I'll try with a much larger program and see if there are any issues. But as you say, perhaps I have a newer rev of the chip. I also just got a 128A3; I'll see if I can get that one working as well.

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

Okay. So I got the bootloader to work on the 128A3 as well. But there was a serious problem with the chip. It appears the PORTD USART is not working. Transmit is fine but the receive flag never clears when you read the data buffer. I worked around the problem by moving to PORTE USART and all is working fine.

-Paul

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

Just for the fun of it, I gave it a go on my Xmega256a3 and ended up with the exact same symptoms as obor00.

avrdude: verification error, first mismatch at byte 0x0000
         0x0c != 0xff

-Raliegh

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

I now have a bootloader working for my xmega192A3. It is a port of the workaround from Atmel application note 1008 (sleep to write) to the assembly code + some changes to the address size passing for some functions. The new bootloader compiles under avrstudio 4.17 with avr-gcc. Once it has been flashed with stk600 + avrstudio through USB, the xmega can be flashed on the stk600 from avrdude + USB/serial cable.

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

obor00 wrote:
I now have a bootloader working for my xmega192A3. It is a port of the workaround from Atmel application note 1008 (sleep to write)

I'm pleased to hear that you were able to make it work, and that the workaround works in practice.

-Raliegh

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

Thanks Raliegh.
I have attached my new version of the bootloader with workaround for Atmega192a3. It should also probably work for x256a3 and lowers with some defines tuning and compilation option. It has been compiled and flash with avr-studio v4.17. Usart speed is set to 19200, Port D. Several options at compilation are needed. It's just a dirty hack.
Olivier

Attachment(s): 

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

Well done. I tweaked as needed and it works nicely on the x256a3.
Thank you.

-Raliegh

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

So that I don't have to spend the rest of my life reading this thread... :)

Does the Xmega128A1 bootloader now work?

Does it work with USARTC0?

Now that we seem to have the USART bridge working reasonably well in the Xplain board (ok a little slowish but 1M times better than original) can this bootloader be used wih the Xplain board?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
So that I don't have to spend the rest of my life reading this thread... :)

Does the Xmega128A1 bootloader now work?

Yes. But check the caveat of the chip revision at the start. About halfway down the first page there is a version wiht fixes.

Quote:

Does it work with USARTC0?

Yes, but you'll need to adjust the config file to suit (simple).

Quote:

Now that we seem to have the USART bridge working reasonably well in the Xplain board (ok a little slowish but 1M times better than original) can this bootloader be used wih the Xplain board?

No idea. Haven't touch an xplain board.

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

Quote:
Haven't touch an xplain board.
That's where I come in :) well if I can get my head around the bootloader mods.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

By the way, I have modified my version of the bootloader to work in 57600bps and not use any pin to enter bootload mode, but timeout (similarly to an arduino).
If anyone is interested, I can put it somewhere in the forum.
Olivier

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

obor00 wrote:
By the way, I have modified my version of the bootloader to work in 57600bps and not use any pin to enter bootload mode, but timeout (similarly to an arduino).
If anyone is interested, I can put it somewhere in the forum.
Olivier

More the merrier.

-- Damien

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

John,

The AVR1605 bootloader works fine on the Xplain board. I just configured for USART #C0 and used PORTF.3 as a handy push-button to hold down during reset.

The supplied AVROSP scripts will not allow a port > COM9. But this is the fault of AvrOsp.exe. I found it easier to reassign to COM8.

The Bootloader will not work with Studio, because Studio will not try 9600 baud.

CodeVision will recognise the Bootloader, but since it does not believe that a STK500 can program an xmega, this does not work either.

However you should find no problem with AvrOsp.exe or with AvrDude.exe

David.

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

Has anyone been able to program Xmega fuse bits with this bootloader? I have not been able to read or write fuse bits with avrdude 5.6 and ATXMega128a3 with my version of the bootloader. Flash and EEPROM work just fine to read or write.

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

Quote:

I have not been able to read or write fuse bits with avrdude 5.6 and ATXMega128a3 with my version of the bootloader. Flash and EEPROM work just fine to read or write.

The Xmega allow running code to write their own fuses do they? No previous AVRs allowed this - it was the common limitation of using a bootloader that not only did you need ISP/JTAG to get the bootloader image programmed in the first place but also to make any fuse adjustments then or later on.

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

Quote:
The AVR1605 bootloader works fine on the Xplain board.
Well then, no need for me to go any further :) I may mess around if I get time, but I don't really need it.

So it may be good to try to push the usart bridge to run a little faster for bootloading purposes?

Anyway if Dean gets the PDI programming working that will be the best solution.

In order to switch between usart bridge and programmer the 2 pins near the SDRAM could be used (GND and PDI), if a link is fitted then go into programming mode otherwise usart bridge mode.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I spoke too soon. I have the AVR1605 loading/saving memory via AVROSP quite happily.

However I am not running bootloaded programs yet. It seems to be in permanent boot mode.

When the PDI programming is working, the xmega should be able to receive the instructions as fast as the 1287 hardware USART can send it.

AVR1605 bootloading at 9600 baud is not for the faint hearted. But the PDI will be the same speed as JTAG.

David.

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

clawson wrote:
Quote:

I have not been able to read or write fuse bits with avrdude 5.6 and ATXMega128a3 with my version of the bootloader. Flash and EEPROM work just fine to read or write.
The Xmega allow running code to write their own fuses do they?
Not really, unless you can issue a PDI Write from inside the running code, which I do not think is possible.

30.12.3NVM Commands 
The NVM commands that can be used for accessing the NVM memories from external programming are listed in Table 30-5. This is a super-set of the commands available for self-programming. 

Fuse Write is one of the 'super-set' commands.

Don't know if the A3 is the same as A1, this is what I do in the A1:

     if(
      /*      (FUSEBYTE0 == SP_ReadFuseByte( 0 ) ) && Manual doesn't match reality, we don't use JTAGID */
      (FUSEBYTE1 == SP_ReadFuseByte( 1 )) &&
      (FUSEBYTE2 == SP_ReadFuseByte( 2 )) &&
      /* There is no FUSEBYTE3 */
      (FUSEBYTE4 == SP_ReadFuseByte( 4 )) &&
      (FUSEBYTE5 == SP_ReadFuseByte( 5 )) &&
      (LOCK_BITS == NVM_LOCKBITS)
     )
    )
    {
      selftest_u16 &= ((uint16_t) ~SELFTEST_FUSES); /*  Passed */
    }
#include 
#define NVM_CMD_READ_FUSES_gc (0x07<<0)	// Read fuse byte

.extern SP_CommonCMD

; ---
; This routine reads the fuse byte given by the index in R24.
;
; Input:
;     R24 - Byte index.
;
; Returns:
;     R24 - Fuse byte.
; ---

.section .text
.global SP_ReadFuseByte

SP_ReadFuseByte:
	sts	NVM_ADDR0, r24              ; Load fuse byte index into NVM Address Register 0.
	clr	r24                         ; Prepare a zero.
	sts	NVM_ADDR1, r24              ; Load zero into NVM Address Register 1.
	sts	NVM_ADDR2, r24              ; Load zero into NVM Address Register 2.
	ldi	r20, NVM_CMD_READ_FUSES_gc  ; Prepare NVM command in R20.
	rcall	SP_CommonCMD                ; Jump to common NVM Action code.
	movw	r24, r22                    ; Move low byte to 1 byte return address.
	ret

Broken out of one of the XMega app. notes:

#include 
#define NVM_CMD_NO_OPERATION_gc (0x00<<0)	// NoOp/Ordinary LPM
#define CCP_IOREG_gc (0xD8<<0)	// IO Register Protection

; ---
; This routine is called by several other routines, and contains common code
; for executing an NVM command, including the return statement itself.
;
; If the operation (NVM command) requires the NVM Address registers to be
; prepared, this must be done before jumping to this routine.
;
; Note that R25:R24:R23:R22 is used for returning results, even if the
; C-domain calling function only expects a single byte or even void.
;
; Input:
;     R20 - NVM Command code.
;
; Returns:
;     R25:R24:R23:R22 - 32-bit result from NVM operation.
; ---

.section .text
.global SP_CommonCMD

SP_CommonCMD:
	sts	NVM_CMD, r20        ; Load command into NVM Command register.
	ldi	r18, CCP_IOREG_gc   ; Prepare Protect IO-register signature in R18.
	ldi	r19, NVM_CMDEX_bm   ; Prepare bitmask for setting NVM Command Execute bit into R19.
	sts	CCP, r18            ; Enable IO-register operation (this disables interrupts for 4 cycles).
	sts	NVM_CTRLA, r19      ; Load bitmask into NVM Control Register A, which executes the command.
	lds	r22, NVM_DATA0      ; Load NVM Data Register 0 into R22.
	lds	r23, NVM_DATA1      ; Load NVM Data Register 1 into R23.
	lds	r24, NVM_DATA2      ; Load NVM Data Register 2 into R24.

	ldi	r25, NVM_CMD_NO_OPERATION_gc ; Prepare NVM command code
	sts	NVM_CMD, r25                 ; Set NVM command to No Operation for clean operation to follow

        clr	r25                 ; Clear R25 in order to return a clean 32-bit value.
	ret
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:

So it may be good to try to push the usart bridge to run a little faster for bootloading purposes?
There is no gain if the memory write time is the speed limiting factor.

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

Quote:
There is no gain if the memory write time is the speed limiting factor.
At 9600 baud every character takes ~1 ms. What's a page buffer size, 512 bytes? I would hope that it would take a lot less than 512ms to write the page.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
Quote:
There is no gain if the memory write time is the speed limiting factor.
At 9600 baud every character takes ~1 ms. What's a page buffer size, 512 bytes? I would hope that it would take a lot less than 512ms to write the page.

Well I'm bootloading on xmega128 using sd flash card and can flash 120kbytes in about 5.5 seconds or so. I think that works out to about 22mS per 512 byte page write including overhead to read from flash card. I would definitely have to agree with John.

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

bpaddock wrote:
js wrote:
Quote:

So it may be good to try to push the usart bridge to run a little faster for bootloading purposes?
There is no gain if the memory write time is the speed limiting factor.

At 57600 the bootloader is significantly faster then the stock 9600 baud when performing flash read and write. Flash erase seems about the same speed.

-Paul

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

Hi everyone,
My application use the last workaround to read/write in flash with sleep during write. I erase and write flash pages and it works. Sometime I have a problem, because flash pages erase/write are not correct.

I have a question about the workaround. In the file sp_driver.s, in function SP_CommonSPM: why rampZ register is saved and restored and not ZH and ZL?

Thanks for your help.

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

I'm in the process of trying to get a bootloader up and running for the XMega256A1. I've compiled and loaded the ported code from this thread which worked ok. However, now I'm trying to port our existing bootloader from Mega2560 to the same XMega.

I am using the assembly file from the ported app note code for flash reading and writing and the rest is a combination of my own and other previously tested XMega app note code.

My problem currently is coming when I compile. I get the error:

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: section .BOOT [00040e40 -> 00040e79] overlaps section .data [00040e40 -> 00040e41]

Is this indicating that my code is too big for the boot section of flash? I'm sure I'm missing something stupid. Thanks for any tips.

edit: I've got rid of all the .boot sections from the sp_driver.s file and replaced them with just .text and it is compiling now. Why did these need to be relocated if the whole .text section is to be relocated to the boot section anyway?

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

cams_mcq wrote:
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/bin/ld.exe: section .BOOT [00040e40 -> 00040e79] overlaps section .data [00040e40 -> 00040e41]

Is this indicating that my code is too big for the boot section of flash?

Yes.

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

Silly question (I know it sounds counter-intuitive) but if programming a bootloader what are you doing with a section called ".BOOT" anyway? A true bootloader should consist of an entire repositioned ".text" section. The LDFAGS should have "-Ttext=0xnnnnn" or it's alternative "--section-start=.text=0xnnnnn". If you don't understand why read the Bootloader FAQ in the Tutorial Forum.

(bottom line is that a bootloader should be a completely stand-alone app - not a subsection of some other app - because one day that app may not be there - it's the same reason BOOTRST should always be enabled when using a bootloader)

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

The .BOOT sections were in the sp_driver.s file I downloaded from the op. I didn't understand why these were there. As I said in my edit above. I changed these to .text and it is now compiling. It's still not working. But it's at least compiling and the code is located in the correct part of the flash.

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

has anyone tried to upload a hex file >64k with avrosp and the bootloader?

I keep getting the message : unequal at address 0x10000!

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

There seems to be a bug in the bootloader. I downloaded the one on the first page of this thread. Is there a later one?

The pin that the bootloader checks to see if it should jump to the application has no pullup. On my Xplain board it always reads low so it never jumps.

The code that allegedly invokes the pullup looks like Mega code to me, and it's copied straight from the code accompaning Appnote AVR1605 Xmega bootloader quick start guide.

To make it work, I changed a line in main.c

//  PROGPORT |= (1<<PROG_NO); // Enable pull-up on PROG_NO line on PROGPORT.
    PROG_CONFIG = PORT_OPC_PULLUP_gc;

and a line in defines.h.

// #define	PROGPORT	PORTF.OUT
#define	PROG_CONFIG PORTF.PIN4CTRL  // port f, pin 4
#define	PROGPIN		PORTF.IN        // port f for xplain board
#define	PROG_NO		PIN4_bp         // I'm using pin 4

Well actually I changed 3 lines because I use port f, pin 4.

So who's crazy. Me and my Xmega, or the rest of the world?

I should mention that I don't use the USB on the Xplain board, except for power. I use usartd1 connected to a serial port on the PC. Going through a level converter, of course.

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

I've tried the XMEGA192 bootloader port here , but I find that it doesn't run correctly when modified for the 64, nor does the unmodified version run in simulation - I've no idea what's going on.

I actually need it to run in a Xmega64A3 , and I've spent days trying things. The atmel test code which writes dummy data from a for loop works, but as soon as you change the dummy data for real stuff it writes rubbish.

I've used the GCC ported workarounds, and all seems fine - until the dummy data is changed for something meaningfull.

I'm totally desperate for a working Xmega64A3 bootloader now, anything that I can hack to my own protocol would be fine.
Helllp!!

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

I don't know what the differences are between Xmegas. I thought they were similar. Damien's port with the fix in my above post works fine on my 128a1. The only things I changed, other than those in the above post, were some configuration changes in defines.h.

You need to change 7 lines in UART control to specify the registers of the USART you are using. All the names that don't end with BIT need to be changed, unless you are using the same USART as Damien. You also need to change 3 lines in "pin for entering self prog mode".

If you have a system clock of 2 MHz and are running at 9600 baud, you don't need to change the baud rate stuff. Beware of the "#define BAUD_RATE 9600" line. It does nothing and should be removed. It's the BRREG_VALUE that sets the baud rate, and it sets it for 9600 baud.

If you want to run faster, I made a few changes that let me also run at 38400 or 115200 baud. I use the BSCALE to let me run at these speeds with a user-unfriendly 2 MHz system clock. I can post my changes if you want.

What programming program are you running on the PC? As far as I can figure out, only avrdude will do the job on Windows. I use the "-c avr911" option.

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

Well, I have finally succeeded in taking the bootload_x192a3 and porting it to the Xmega64A3.

I started a completely new project and copied all the relevant files to it - plus some of my own io configuring and at long last it seems to work - over a bluetooth link too!.

It writes both Flash and EEprom using the workaround.

:)

What Windows based programmer will connect to this?
Have I got to write one myself ( Oh dear ) - I cant expect my customer to use something complex like avr studio ... so what does everyone else use - that works with the XMega?

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

KaiB wrote:
has anyone tried to upload a hex file >64k with avrosp and the bootloader?

I keep getting the message : unequal at address 0x10000!

I contacted Atmel abut this; it is caused by issues when shifting one bit left on the address variable in the actual bootloader.

They send me a new main.c file:

Attachment(s): 

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

After trying for over eight hours, I still can't get the bootloader to work right on my XMega256A3. Here's what I've done so far (not particularly in order):

- Downloaded the workaround code from obor00 (bootload_x192a3.zip).

- Modified the code:
- Uses USARTC0
- Triggers on PinD.7.
- Changed baud rate to 38400 (using BSCALE=-1, BREG=11)
- Added "#define FLASH_PAGE_SIZE 512" to cure compile failure.
- Changed "#define APP_END 0x40000".

- Programmed the BOOTRST fuse bit using AVR Studio
- Added "-Wl,-section-start=.text=0x40000" to the compiler and linker commands.
- Use avr-objcopy to create a raw binary.
- Send the bootloader binary using AVRDude and AVRISP-mkII to the chip using: "avrdude -c avrispmkII -p x256a3 -P usb -e -U boot:w:bootload.bin"
- Send the main application to the bootloader using: "avrdude -p x256a3 -P /dev/ttyUSB0 -c avr911 -b 38400 -e -U flash:w:myprogram.hex"

AVRDude does the following:

...

avrdude: writing flash (13038 bytes):

Writing | ################################################## | 100% 4.62s

...

avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.95s


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

Versions: avr-gcc 4.3.4, AVRDude 5.10.

Any ideas?

_________________
Brad Nelson
http://bradsprojects.wordpress.com

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

rowifi wrote:
I've tried the XMEGA192 bootloader port here , but I find that it doesn't run correctly when modified for the 64, nor does the unmodified version run in simulation - I've no idea what's going on.

I actually need it to run in a Xmega64A3 , and I've spent days trying things. The atmel test code which writes dummy data from a for loop works, but as soon as you change the dummy data for real stuff it writes rubbish.

I've used the GCC ported workarounds, and all seems fine - until the dummy data is changed for something meaningfull.

I'm totally desperate for a working Xmega64A3 bootloader now, anything that I can hack to my own protocol would be fine.
Helllp!!

I just released XBoot, a modular bootloader that should work for you. Post here: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=701069

I tested it on a 64a3, so it darn well better work on yours. And it's compatible with AVRDUDE out of the box, so you won't have to go implement your own protocol.

Alex Forencich

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

radbrad wrote:
After trying for over eight hours, I still can't get the bootloader to work right on my XMega256A3.

[snip]

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

I got nailed by that as well. AVRDude 5.10 is broken - it can't program the boot block on any XMega series part. See bug report: https://savannah.nongnu.org/bugs/?28744. The fix is posted, all you need to do is nab AVRDude from the repository, patch it with my patch listed in the bug report, and then compile and install it. It will be able to download the bootloader when you're done.

Also, check out my new XBoot bootloader for XMega. It should be very easily reconfigurable for all XMega series parts: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=93351.

Alex Forencich

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

Awesome, bro! Thanks for the help, I'll probably give your bootloader a shot also. After I finish my Mother's Day dish duty, I'll give it a shot and let you know how it works.

_________________
Brad Nelson
http://bradsprojects.wordpress.com

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

... and can't help wondering - where were you yesterday! ;)

_________________
Brad Nelson
http://bradsprojects.wordpress.com

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

radbrad wrote:
... and can't help wondering - where were you yesterday! ;)

Incidentally, on a shopping trip to several electronics surplus shops buying various electronics goodies that culminated in the biggest diode I've ever seen. No joke. It's a 450V/400A diode. Got it for ten bucks. And no, I have absolutely no good use for it besides a desk ornament.

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

Still no taco. It's actually a step back from the other one - at least the other one would get through the program. Here's the output:

avrdude -p x256a3 -P /dev/ttyUSB0 -c avr911 -b 38400 -e -U flash:w:myprogram.hex

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

Programmer supports the following devices:
    Device code: 0x7b

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9842
avrdude: erasing chip
avrdude: butterfly_recv(): programmer is not responding

_________________
Brad Nelson
http://bradsprojects.wordpress.com

Pages