View topic - New xmega Bootloader (App Note AVR1605)

Search

New xmega Bootloader (App Note AVR1605) - Port to GCC
Previous 1, 2, 3, 4, 5, 6, 7, 8 Next All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » XMEGA forum

Author

Message

Posted: Dec 04, 2009 - 09:47 PM

Joined: Mar 28, 2001
Posts: 20635
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)

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

telliott

Posted: Dec 04, 2009 - 10:20 PM

Joined: Nov 06, 2006
Posts: 292
Location: Wa, USA

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.

wandererwolf

Posted: Dec 08, 2009 - 05:37 PM

Joined: Oct 30, 2006
Posts: 29
Location: Boston, MA

bpaddock wrote:

[quote="js"]

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

florian_germain

Posted: Feb 13, 2010 - 08:00 AM

Joined: Feb 10, 2010
Posts: 1

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.

cams_mcq

Posted: Feb 26, 2010 - 02:33 AM

Joined: Oct 02, 2009
Posts: 13
Location: Brisbane, Australia

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?

damien_d

Posted: Feb 26, 2010 - 08:53 AM

Joined: Dec 15, 2008
Posts: 923
Location: Brisbane, Australia

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.

clawson

Posted: Feb 26, 2010 - 11:19 AM

Joined: Jul 18, 2005
Posts: 62944
Location: (using avr-gcc in) Finchingfield, Essex, England

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)

_________________

cams_mcq

Posted: Mar 01, 2010 - 01:28 AM

Joined: Oct 02, 2009
Posts: 13
Location: Brisbane, Australia

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.

KaiB

Posted: Apr 20, 2010 - 08:06 AM

Joined: Oct 14, 2009
Posts: 3

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

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

steve17

Posted: May 02, 2010 - 12:04 AM

Joined: Sep 07, 2004
Posts: 2564
Location: New York State

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

Code:

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

Code:

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

rowifi

Posted: May 02, 2010 - 05:11 PM

Joined: Mar 30, 2005
Posts: 57

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

steve17

Posted: May 02, 2010 - 08:25 PM

Joined: Sep 07, 2004
Posts: 2564
Location: New York State

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.

rowifi

Posted: May 02, 2010 - 10:41 PM

Joined: Mar 30, 2005
Posts: 57

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.

Smile

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?

KaiB

Posted: May 03, 2010 - 02:56 PM

Joined: Oct 14, 2009
Posts: 3

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:

radbrad

Posted: May 09, 2010 - 09:59 PM

Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon

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:

Code:

...

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?

alex.forencich

Posted: May 10, 2010 - 01:02 AM

Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA

rowifi wrote:

I just released XBoot, a modular bootloader that should work for you. Post here: http://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

alex.forencich

Posted: May 10, 2010 - 01:19 AM

Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA

radbrad wrote:

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

[snip]

Code:

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: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=93351.

Alex Forencich

radbrad

Posted: May 10, 2010 - 02:04 AM

Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon

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

radbrad

Posted: May 10, 2010 - 02:10 AM

Joined: Mar 31, 2006
Posts: 48
Location: Corvallis, Oregon

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

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

alex.forencich

Posted: May 10, 2010 - 02:32 AM

Joined: Apr 01, 2010
Posts: 68
Location: San Diego, CA

radbrad wrote:

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

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.

Jump to:

All times are GMT + 1 Hour

Previous 1, 2, 3, 4, 5, 6, 7, 8 Next All

AVR Freaks Forum Index » AVR (8-bit) Technical Forums » XMEGA forum

AVRFreaks.net

Search