View topic - New xmega Bootloader (App Note AVR1605)

Search

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

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

Author

Message

damien_d

Posted: May 28, 2009 - 07:33 AM

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

Recently, Atmel has (finally!) released a bootloader application note for the xmega (ATxmega128A1).

However, the application note only includes a workspace for the IAR compiler.

I have attached below a port of this bootloader to using GCC. The changes to the original are as follows:

* Changed headers where needed to <avr/io.h>
* Linked in the sp routines (for gcc) from Application note AVR1316
* Changed (using the gui) to link .text to 0x10000 words

It works with the supplied demo hex files in the application notes, but I am yet to push it very hard.

Code below is available under the same 3-clause BSD licence that ATMEL use in their application note code.

Comments are welcome.

-- Damien

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

WARNING! The boot flash is not functional in Revision G and below of the ATxmega128A1. Double check you have Rev H or later before proceeding - see in this thread how to check.

(Edit: Added warning about xmega silicon revision required).

Last edited by damien_d on Jun 10, 2009 - 09:39 AM; edited 2 times in total

Posted: May 28, 2009 - 08:48 AM

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

Quote:

Atmel has (finally!) released a bootloader application note for the xmega

Must be getting real close now to releasing the Xmegas then.. Confused

_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly

tostmann

Posted: May 29, 2009 - 12:19 AM

Joined: May 28, 2009
Posts: 1

Thanks, good work!
In order to use it under Linux with avrdude I found two things:

avrdude needed "-e" (chip erase) to work properly

Changed to 19200 baud, so avrdude doesn't need extra baud parameter. Also added CLK2X-bit so bitrate error gets reduced.

In general:
There is a PORTX.OUT = something;
to pullup the prog key (which doesn't worked).
AtXmega is using now PORTX.PINYCTRL = 0x18;
to pull inputs (which works). Right? Wrong?

Result works great! Find patched project zipped here: http://busware.de/tiki-download_file.php?fileId=22

damien_d

Posted: May 29, 2009 - 04:51 AM

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

To follow up, I have noticed that for Windows users, if you have a programmer based on AVR911 (AVR open-source porgrammer), then you'll need to use the exe supplied with the AVR1605 application note - the old version seems to not want to work with it.

Unfortunantly, there is no updates to the sources for the AVROSP supplied with the application note (i.e. it's binary only). I'm putting in a support request to see if they're willing to release the updated sources.

-- Damien.

telliott

Posted: May 30, 2009 - 08:14 PM

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

Damien,

Thanks for posting this. It just made my day a lot better.

clawson

Posted: May 30, 2009 - 08:26 PM

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

Quote:

Unfortunantly, there is no updates to the sources for the AVROSP supplied with the application note (i.e. it's binary only). I'm putting in a support request to see if they're willing to release the updated sources.

It'd be a bit sad if they weren't given what the OS in AVROSP stands for!

_________________

damien_d

Posted: Jun 08, 2009 - 12:51 AM

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

To update, Atmel support have taken the request to release the AVROSP source on notice and will get back to me when they have made a decision.

bpaddock

Posted: Jun 09, 2009 - 09:05 PM

Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh

damien_d wrote:

Dear All,

Recently, Atmel has (finally!) released a bootloader application note for the xmega (ATxmega128A1).
...
I have attached below a port of this bootloader to using GCC....

I just tried to fire up this code on my Xmega board. At the start of main I'm just trying
to light a LED:

Code:

#define LED_BOTTOM_YELLOW_bp (5)

#define LED_BOTTOM_YELLOW_bm _BV(LED_BOTTOM_YELLOW_bp)

int main(void)

{

    PORTC.OUT    = LED_BOTTOM_YELLOW_bm;

    PORTC.DIR    = LED_BOTTOM_YELLOW_bm;

    PORTC.OUTCLR = LED_BOTTOM_YELLOW_bm;

    for(;;)

      ;

}

I'm not getting any yellow LED when I set the boot reset vector fuse.

I do get the yellow LED when I don't set the boot vector fuse, and remove the .text=0x10000 [in words] under the Memory Settings Option dialog. So I assume I'm not jumping to the boot code when the fuse is set. Is there something else that needs set in the fuses besides the boot reset fuse?

I know the board works in non-boot mode.

damien_d

Posted: Jun 10, 2009 - 09:35 AM

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

bpaddock wrote:

I do get the yellow LED when I don't set the boot vector fuse, and remove the .text=0x10000 [in words] under the Memory Settings Option dialog. So I assume I'm not jumping to the boot code when the fuse is set. Is there something else that needs set in the fuses besides the boot reset fuse?

I know the board works in non-boot mode.

Double check that you have a Revision H chip and not a Revision G chip - there is an errata in Rev G where the boot flash is not functional (at all).

Not sure if there's any markings on the chip, but if you look at "4.19.4 REVID - MCU Revision ID" on p36 of the reference manual, you'll be able to determine the chip revision.

bpaddock

Posted: Jun 10, 2009 - 12:47 PM

Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh

damien_d wrote:

I'm sure I have a RevH part, I have the following code
displaying the rev and serial number:

Code:

/* hex8 converts the passed byte to ASCII in a buffer.

   offsetof() comes from stddef.h

 */

  /* Read the part signature and revision: */

  hex8( MCU.DEVID0 );

  hex8( MCU.DEVID1 );

  hex8( MCU.DEVID2 );

  *buf_ptr_u8++= (uint8_t) (MCU.REVID+'A');

  /* Device serial number: */

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, LOTNUM0 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, LOTNUM1 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, LOTNUM2 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, LOTNUM3 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, LOTNUM4 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, LOTNUM5 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, WAFNUM ) )  );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, COORDX0 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, COORDX1 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, COORDY0 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, COORDY1 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, TEMPSENSE0 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, TEMPSENSE1 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, ADCACAL0 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, ADCACAL1 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, ADCBCAL0 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, ADCBCAL1 ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, DACAOFFCAL ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, DACACAINCAL ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, DACBOFFCAL ) ) );

  hex8( SP_ReadCalibrationByteC( offsetof( NVM_PROD_SIGNATURES_t, DACBGAINCAL ) ) );

How are you getting your bootloader code into your chip?
I'm using the JTAG-MK-II with Studio. I did note that if I read the
chip it stops reading at 0x1FFFF. So I'm not convinced that
the code is even being programmed into 0x20000 at all.

damien_d

Posted: Jun 10, 2009 - 01:11 PM

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

Quote:

Code:

*buf_ptr_u8++= (uint8_t) (MCU.REVID+'A');

The operator precedence is hurting by head. This is the same as (I think! please correct me if I'm wrong), and if so, it's ok:

Code:

*buf_ptr_u8 = (uint8_t) (MCU.REVID +'A'); 

buf_ptr_u8++;

How does that actually appear in your display without the Hex8 call?

I believe the raw value should be 7, but I can't confirm that without an xmega board in front of me.

If you're using JTAG and AVR studio, you can jusf go straight in and look at the I/O registers directly for it.

bpaddock wrote:

We're also using JTAG-MkII with AVR Studio. Try opening up flash and looking at the Window at (byte) 0x20000 - you'll see code there of some description if it's in the correct place.

Failing that, can you post your linker map (or better yet, the whole project), and I may be able to have a bit of a look at it.

-- Damien

bpaddock

Posted: Jun 10, 2009 - 02:30 PM

Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh

Quote:

The operator precedence is hurting by head. This is the same as (I think! please correct me if I'm wrong), and if so, it's ok:

Code:

*buf_ptr_u8 = (uint8_t) (MCU.REVID +'A');

buf_ptr_u8++;

The '*' binds tighter than the ++/-- operator.

Quote:

How does that actually appear in your display without the Hex8 call?

Application code works fine, the values displayed match what Studio shows under the advance tab
for the value of the production_signature registers.

Quote:

I believe the raw value should be 7, but I can't confirm that without an xmega board in front of me.

It says RevH on the bottom of the chip. I'd like to know who thought it was a good idea to put that on the bottom of the chip.

Quote:

Failing that, can you post your linker map (or better yet, the whole project), and I may be able to have a bit of a look at it.

The bootloader code is your port of 1605, only change was to light the LED on the appropriate pin on my hardware, as shown in my post above.

What I have found is that if the boot reset vector fuse is set, and I have the JTAG cable plugged in to my target board, no code runs, not the application code, not the bootloader code. If I unplug the JTAG cable from the target board and cycle power to my board, then the bootloader code runs.

If the boot reset vector bit is not programmed then my application code runs regardless of having the JTAG cable plugged in or not.

?

damien_d

Posted: Jun 11, 2009 - 01:47 AM

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

tostmann wrote:

I have confirmed the fixes above when using with avrdude 5.6 on Ubuntu 8.04 (x86).

Note that the avrdude package on Ubuntu 8.04 is actually 5.5, which does not support xmega. You'll need to download and compile the avrdude sources yourself.

mgh148

Posted: Aug 26, 2009 - 02:34 PM

Joined: Sep 18, 2007
Posts: 45

Hi Everyone,

I wonder if someone can help with the bootloader.

I have all the stuff from the AVR1605 App note and I loaded the code with the bootloader.

Now the problem is when I switch the fuse from application reset to bootloader reset and load the code I am unable to run it. It looks like it is running in the bootloader section. I tried to reset it after but it seems like the data is corrupt or it is not jumping to the application section. How do I load the code with the bootloader reset enabled?

bpaddock

Posted: Aug 26, 2009 - 06:53 PM

Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh

mgh148 wrote:

How do I load the code with the bootloader reset enabled?

I'm assuming you mean run, not load, the code from your other comments? This is what I do at the end of my XMega
bootloader:

Code:

  /*

   * Return boot vectors to application space, then jump to the reset

   * vector:

   */

  byte_u8 = (PMIC.CTRL & ((uint8_t) ~PMIC_IVSEL_bm));

  CCPWrite( &PMIC.CTRL, byte_u8 );

  RAMPZ = 0;

  EIND  = 0;

  __asm__ __volatile__ ("jmp 0x0000\n\t" ::);

Make sure you have the EIND = 0.

mgh148

Posted: Aug 28, 2009 - 06:58 PM

Joined: Sep 18, 2007
Posts: 45

Hi bpaddock,

After careful review I think I main have found my issue. It's the enter bootloader mode while the pin is low.

Quote:

if( !(PROGPIN & (1<<PROG_NO)) ) // If PROGPIN is pulled low, enter programmingmode.

That pin appears to be the 4th pin on port D, which for me is always low since it's not used. I tried to instead add a timer in the recchar() function, so that if I don't receive a character in 10 seconds then jump to application code.
That's not seeming to work either. Do you guys have any ideas of how I can do this, since I can't physically change any pin?

Thanks in advance.

mgh148

Posted: Sep 02, 2009 - 10:29 PM

Joined: Sep 18, 2007
Posts: 45

Hi everyone,

Okay, I have an update I managed to get add the timer to the bootloader code, so that it jumps to application code after a certain amount of time. It seems like it only works sometimes though.
Any incite on where my error could be?

This what I edited in serial.c

Code:

void TC_SetOneSecTimer()

{

   /* Set period/TOP value. */

   TC_SetPeriod( &TCC0, 0x1000);

   /* Select clock source. */

   TC0_ConfigClockSource( &TCC0, TC_CLKSEL_DIV1024_gc );

}

void TC_ClearOneSecTimer()

{

   TC0_ConfigClockSource( &TCC0, TC_CLKSEL_OFF_gc );

}

unsigned char recchar(void)

{

    unsigned char ret, tCounter;

   static unsigned char x=0;   //check to see if first character is received in time

   tCounter = 0;

   if(x == 0)

   {

      TC_SetOneSecTimer();

   }

   while(!(UART_STATUS_REG & (1 << RECEIVE_COMPLETE_BIT)))  // wait for data

   {

      if(TC_GetOverflowFlag( &TCC0 ))

      {

         tCounter++;   

      }

      if(tCounter >= 5){ TC_ClearOneSecTimer(); tCounter=0; return 'E';}   //if timed out send E which jumps to application code.

   }

   x=1;               //if first character is received stay in bootmode

   TC_ClearOneSecTimer();

    ret = UART_DATA_REG;

     return ret;

}

damien_d

Posted: Sep 02, 2009 - 11:32 PM

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

Quote:

Code:

 while(!(UART_STATUS_REG & (1 << RECEIVE_COMPLETE_BIT)))  // wait for data

   {

      if(TC_GetOverflowFlag( &TCC0 ))

      {

         tCounter++;   

      }

If you never get a byte, you'll never enter the loop to check for the overflow flag.

-- Damien

ScottKroeger

Posted: Oct 08, 2009 - 02:43 PM

Joined: Feb 22, 2002
Posts: 220

Hi Gang,

I've rebuilt tostmann's port for the ATxmega16A4, moving the text section to 0x2000 and changing the flash/eeprom page/total sizes accordingly. Now, when I run AVROSP and attempt to read flash, I get the following error message:

An error occurred: Programmer pagesize is not set!

I can't see a place in the bootstrap code where AVROSP might inquire about that, so I'm wondering if this is a problem inside AVROSP and its reading of the .XML config files.

Anyone got an idea?

damien_d

Posted: Oct 09, 2009 - 12:07 AM

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

ScottKroeger wrote:

I can't see a place in the bootstrap code where AVROSP might inquire about that, so I'm wondering if this is a problem inside AVROSP and its reading of the .XML config files.

Anyone got an idea?

Only the binaries for the AVROSP shipped with the xmega bootloader application note will load it - the structure of the XML files have changes significantly for the xmega devices which the original application note doesn't recognise.

I asked nicely for the source for the new AVROSP but unfortunately never received it.

-- Damien

ScottKroeger

Posted: Oct 09, 2009 - 03:42 AM

Joined: Feb 22, 2002
Posts: 220

I am using the version of AVROSP from the AVR1605 app note (dated 4-30-2009). I've also verified that the part description .XML file is being read and cached, so maybe that's not the issue.

ScottKroeger

Posted: Oct 09, 2009 - 06:03 PM

Joined: Feb 22, 2002
Posts: 220

I've looked through the sources in AVR911 (AVROSP) and the pagesize error message I get is consistent with that older version of program trying to read a new xmega .XML file. The flash pagesize is specified differently in the new XML file and the old AVROSP program would not find it.

However this doesn't match up with the claim that the version of AVROSP included in AVR1605 is newer and matched to the new format of the XML part description files.

Damien, it seems to me that you should have seen this problem, unless your xmega128 part description file is in an older format than that found in WinAVR-20090313

ScottKroeger

Posted: Oct 09, 2009 - 09:54 PM

Joined: Feb 22, 2002
Posts: 220

The original AVR911 AVROSP doesn't recognize the new part description files included in AVRStudio/WinAVR, neither does the new version in the AVR1605 app note. AVR1605 contains a single part description file for the ATxmega128A1, which is different from that in WinAVR.

So, it appears that the only part one can currently program with the new AVROSP is the ATxmega128A1.

It's a shame Atmel didn't release the sources for the new version. They're clearly not managing this well themselves.

I think the PAGESIZE parameter is the only thing missing, so I'll hand modify the cached .XML file and see what happens.

damien_d

Posted: Oct 10, 2009 - 04:31 AM

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

Have you tried using the XML files supplied with new versions of AVR studio? I seem to remember there was a bug in one of the descriptions with the old version, but my memory is a little hazy.

-- Damien

stevech

Posted: Oct 10, 2009 - 06:29 PM

Joined: Dec 18, 2001
Posts: 4716

damien_d wrote:

The latest XML files are OK. BLIPS' PC side reads them to find out page size, etc. There were some errors in the files earlier this year.

wandererwolf

Posted: Oct 15, 2009 - 05:35 PM

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

Is there any chance they will release a new binary to go with the application note? I want to try to get a AVRosp compatible bootloader running on a new version of this board:

http://www.bostonandroid.com/products.html

It just looks like a lot of work to write the pc app and the bootloader for a new Xmega.

-Paul

damien_d

Posted: Oct 16, 2009 - 09:06 AM

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

wandererwolf wrote:

IIRC (it's been some months) avrdude works nicely with the application note, if you don't want to write the host side from scratch. It requires a small update to the parts description file for the 16A4, but other than that, it seems to work fine.

-- Damien

mannu4u

Posted: Oct 21, 2009 - 03:09 PM

Joined: Feb 06, 2009
Posts: 4

Hi damien_d,

I extracted the zip file which you uploaded in the freaks and loaded it through JTAG but the functionality seems not working. I haven't changed anything. When i saw the UART registers and PORTD registers in the IO View, they were not updated. I haven't enable any of the Fuse bits except the default ones.

Could you please give any suggestion why iam not able to work on this.

NOTE:
-----
I tried to Toggle the LED's from bootloader section on the STK600, but helpless. Same thing works from Application section.

--
Manohar

damien_d

Posted: Oct 21, 2009 - 11:33 PM

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

mannu4u wrote:

Could you please give any suggestion why iam not able to work on this.

Just to rule out the easy things first, are you using AVR Studio 4.17 and have you confirmed you've got a revision H chip or greater (assuming a 128A1)?

-- Damien

mannu4u

Posted: Oct 22, 2009 - 06:07 AM

Joined: Feb 06, 2009
Posts: 4

@damien,

We are using atxmega128a1-Revision H chip, but the AVR studio version is 4.15.

damien_d

Posted: Oct 22, 2009 - 08:47 AM

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

mannu4u wrote:

We are using atxmega128a1-Revision H chip, but the AVR studio version is 4.15.

A couple of people have had issues with accessing the boot flash of the xmega devices prior to 4.17 - see http://www.avrfreaks.net/index.php?name ... mp;t=72483 . Please upgrade AVR Studio and try again.

-- Damien

mannu4u

Posted: Oct 22, 2009 - 01:33 PM

Joined: Feb 06, 2009
Posts: 4

@damien,

I tried the same project by upgrading AVR studio to 4.17 from 4.15, but the things were not changed. Is i need to set any fuse byte or change configuration options?

damien_d

Posted: Oct 22, 2009 - 02:12 PM

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

mannu4u wrote:

@damien,

I tried the same project by upgrading AVR studio to 4.17 from 4.15, but the things were not changed. Is i need to set any fuse byte or change configuration options?

There is a fuse setting for the reset to start executing from bootloader space, rather than application space.

mannu4u

Posted: Oct 22, 2009 - 03:24 PM

Joined: Feb 06, 2009
Posts: 4

Sorry to mention, i did that change.

rajendar.k

Posted: Oct 23, 2009 - 05:16 AM

Joined: Dec 22, 2008
Posts: 14

Hi,

I have a similar problem as @mannu4u,when trying to bootload.

When I debug the bootloader program in the AVR Studio, the registers related to the Uart are getting updated in the I/O view.
When the same progam is moved to application section(.text starts at 0x0), I am able to see the Uart registers getting updated in the I/O view. I am also able to echo some bytes over uart and see them in hyperterminal.
I am trying this with ATxMega64A1 and AVR Studio 4.17.

Regards,
Rajendar

damien_d

Posted: Oct 23, 2009 - 07:05 AM

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

rajendar.k wrote:

I am trying this with ATxMega64A1 and AVR Studio 4.17.

Just ruling out simple things, did you change the makefile/configuration to start from something other than 0x10000 words (i.e. 0x8000 words for a 64K device)?

-- Damien

rajendar.k

Posted: Oct 23, 2009 - 07:15 AM

Joined: Dec 22, 2008
Posts: 14

Hi damien_d,

Yes, I have given text section start address as 0x8000(for Xmega64A1) from the memory configuaration option of the project.
I have also programmed the BOOT_RST fuse to bootloader reset.

Regards,
Rajendar

damien_d

Posted: Oct 24, 2009 - 05:16 AM

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

rajendar.k wrote:

Yes, I have given text section start address as 0x8000(for Xmega64A1) from the memory configuaration option of the project.
I have also programmed the BOOT_RST fuse to bootloader reset.

When linked to Bootloader space, can you do anything simple, like flash an LED or just send "hello" out the UART?

Do you have a 128A1 sample you can attempt on?

-- Damien

rajendar.k

Posted: Oct 24, 2009 - 09:10 AM

Joined: Dec 22, 2008
Posts: 14

@damiend,
I have tried programming Uart,timer,GPIO(leds) etc, but none of them worked. Like timer never fires and when its registers are inspected(I/O view of Studio), they dont get programmed at all.

When I take a sample piece of code(leds toggler) binary into a data memory buffer(say an array), I am able to write it to Application section of the FLASH. (This program .text is at 0x10000(for 128a1) and BOOT_RST fuse is programmed to bootloader reset). The flashed program even runs.
Problem starts when I try to get those program bytes over uart. NVM controller is getting programmed but not the peripherals.
There is another observation.If we put all the user code to boot section and leave the IVT, reset vector (all init code before main is invoked) etc in App section, the uart echo program works.

I am not able to attach the sample programs.

Regards,
Rajendar

rajendar.k

Posted: Oct 24, 2009 - 09:14 AM

Joined: Dec 22, 2008
Posts: 14

damien_d,

Please find some attachments.
In uart_samp.zip, please give .mycode section some address in the bootsection. [By replacing .mycode with .text(in uart.c), whole program text can be put either at App sec start or boot sec start(I am not able to attach some more samples)]
flash_prog_samp.zip has the sources and headers and .text can be linked from project memory config options. This writes some sample binary to app section of flash.

Regards,
Rajendar

rajendar.k

Posted: Oct 27, 2009 - 06:17 AM

Joined: Dec 22, 2008
Posts: 14

@damiend,
I am able to see (in I/O view) only CCP (a CPU register) register getting modified (in a program starting at Bootsection) and nothing else.

The part number on the device is AU 0848(REV H). For REV G, it starts with ES. Please Correct me if I am wrong ?

Regards,
Rajendar

damien_d

Posted: Oct 27, 2009 - 07:32 AM

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

Code:

uint8_t selfprog_uart_getchar() __attribute__((section(".mycode")));

Don't bother with this - just link the .text section to said location in bootloader space and give that a shot.

For the bootloader, you'll want **everything** in the bootloader space. Don't try to compile your application code with it - it should be an entirely separate project.

-- Damien

clawson

Posted: Oct 27, 2009 - 10:21 AM

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

Quote:

For the bootloader, you'll want **everything** in the bootloader space. Don't try to compile your application code with it - it should be an entirely separate project.

Rajendar,

If these things weren't obvious you may want to read the Bootloader FAQ

_________________

rajendar.k

Posted: Oct 27, 2009 - 01:11 PM

Joined: Dec 22, 2008
Posts: 14

Dear damiend,
I have tried running the bootloader uploaded by you.

When I run your bootloader and inspect the Uart registers, they are not getting programmed. The AVROSP also quits reporting error.Bootloader is not working for me.

Bootloader can be seen as flash programming + receiving program binary over uart. Alone flash programming works fine. But flash programming with uart(for receiving program from PC etc) is not working. Also Uart (or timer,GPIO etc) alone program is also not working(.text at Boot section start,BOOT_RST as Bootloader Reset).

The same Uart program(or timer,GPIO etc) works when run in Application section(.text at Application section start,BOOT_RST as Application Reset).[And we cannot run Flash programming in Application section as it is RWW only]

I sent you the samples to show above facts and to know if I am doing anything wrong.[Even your unchanged bootloader doesnt work for me].I always wanted to run the bootloader as a separate program with everything in BOOTSECTION.

Regards,
Rajendar

clawson

Posted: Oct 27, 2009 - 02:15 PM

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

Well to rule things out try placing an LED flasher at the bootloader address and then have it entered by the BOOTRST fuse - does that work. A common error is to mis-position the bootloader code

Quote:

I always wanted to run the bootloader as a separate program with everything in BOOTSECTION.

If by BOOTSECTION you mean GCC's BOOTLOADER_SECTION then (as shown in the FAQ) that is NOT the way to do it. BOOTLOADER_SECTION (despite the name) is not normally involved in a bootloader (only an app that needs to do SPM). To position a separate bootloader program at the BOOTRST address you just use linker commands to re-position .text to the Bootloader Section boundary address.

Cliff

_________________

obor00

Posted: Oct 27, 2009 - 10:22 PM

Joined: Aug 28, 2008
Posts: 82
Location: France

Hi,
I am also fighting with atxmega bootloader. Once bootloader installed, I get an error when flashing a basic application. avrdude passes successfully the device recognition (I changed the id to match my xmega192A3), but after reading/writing, it gives the following error:

Code:

avrdude: verifying ...

avrdude: verification error, first mismatch at byte 0x0006

         0x15 != 0x0d

avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

The command I use to launch avrdude is:

Code:

avrdude -p x192a3 -P /dev/ttyUSB0 -c avr911 -b 9600 -U flash:w:blink.hex

All code is compiled with -D F_CPU=16000000, and I am using USB FTDI converter to convert signals from USB to serial:
http://www.sparkfun.com/commerce/produc ... ts_id=8772

Any idea what could be wrong ?

damien_d

Posted: Oct 27, 2009 - 10:32 PM

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

obor00 wrote:

The command I use to launch avrdude is:

Code:

avrdude -p x192a3 -P /dev/ttyUSB0 -c avr911 -b 9600 -U flash:w:blink.hex

You'll need the erase option of avrdude as well (-e IIRC). I don't think it erases the flash without it and hence, it will have left-over cleared bits from the previous program

-- Damien

obor00

Posted: Oct 28, 2009 - 08:25 AM

Joined: Aug 28, 2008
Posts: 82
Location: France

damien_d wrote:

You'll need the erase option of avrdude as well (-e IIRC). I don't think it erases the flash without it and hence, it will have left-over cleared bits from the previous program

Thanks for the suggestion, I will try. But Ox15=10101 while 0xd=1101 so this is not the same bit, so I am not sure that erase will fix it.
Does someone has any hint how further locate where the problem is: Bits transmission, flash writing problem ?

obor00

Posted: Oct 28, 2009 - 06:22 PM

Joined: Aug 28, 2008
Posts: 82
Location: France

With erase option, I get a new error:

Code:

avrdude: input file blink.hex auto detected as Intel Hex

avrdude: writing flash (708 bytes):

Writing |                                                    | 0% 0.00savrdude: error: programmer did not respond to command: set addr

rajendar.k

Posted: Oct 29, 2009 - 06:14 AM

Joined: Dec 22, 2008
Posts: 14

Dear Cliff,

Quote:

If by BOOTSECTION you mean GCC's BOOTLOADER_SECTION then (as shown in the FAQ) that is NOT the way to do it.

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

Regards,
Rajendar

damien_d

Posted: Oct 29, 2009 - 09:37 AM

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

obor00 wrote:

Code:

avrdude -p x192a3 -P /dev/ttyUSB0 -c avr911 -b 9600 -U flash:w:blink.hex

Is the x192a3 implemented in the avrdude.conf file? If so, can you verify that the parameters (such as page size) match what is expected by the bootloader - I seem to recall there are some #define settings for that.

My original target was a big hack job for the 128A1 only (I use a different bootloader for my own stuff now).

Quote:

All code is compiled with -D F_CPU=16000000

You have adjusted the UART BSEL etc, haven't you (I think my original had it at 2MHz)? Just checking the simple stuff Smile

-- Damien

damien_d

Posted: Oct 29, 2009 - 09:39 AM

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

rajendar.k wrote:

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

rajendar.k

Posted: Oct 29, 2009 - 10:39 AM

Joined: Dec 22, 2008
Posts: 14

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

rajendar.k

Posted: Oct 29, 2009 - 11:04 AM

Joined: Dec 22, 2008
Posts: 14

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

damien_d

Posted: Oct 29, 2009 - 11:57 AM

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

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

rajendar.k

Posted: Oct 29, 2009 - 12:36 PM

Joined: Dec 22, 2008
Posts: 14

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

Regards,
Rajendar

obor00

Posted: Oct 29, 2009 - 10:52 PM

Joined: Aug 28, 2008
Posts: 82
Location: France

Still no success for me Sad

I checked clock speed, bootloader section location, -e, lock bits etc... I always get an error:

Code:

avrdude: verifying ...

avrdude: verification error, first mismatch at byte 0x0000

         0x0c != 0xff

avrdude: verification error; content mismatch

with the erase option, I get timeout:

Code:

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 ?

obor00

Posted: Nov 04, 2009 - 03:41 PM

Joined: Aug 28, 2008
Posts: 82
Location: France

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

wandererwolf

Posted: Nov 05, 2009 - 12:11 AM

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

I just got damien_d's port of the AVR1605 note to avr-gcc to work on the www.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

obor00

Posted: Nov 05, 2009 - 08:47 AM

Joined: Aug 28, 2008
Posts: 82
Location: France

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.

damien_d

Posted: Nov 05, 2009 - 01:07 PM

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

wandererwolf wrote:

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

-- Damien

wandererwolf

Posted: Nov 05, 2009 - 01:14 PM

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

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.

wandererwolf

Posted: Nov 07, 2009 - 01:35 PM

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

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

Raliegh

Posted: Nov 08, 2009 - 02:17 AM

Joined: Jan 15, 2009
Posts: 15

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

Code:

avrdude: verification error, first mismatch at byte 0x0000

         0x0c != 0xff

obor00

Posted: Nov 10, 2009 - 10:53 PM

Joined: Aug 28, 2008
Posts: 82
Location: France

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.

Raliegh

Posted: Nov 11, 2009 - 01:36 AM

Joined: Jan 15, 2009
Posts: 15

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

obor00

Posted: Nov 11, 2009 - 10:02 PM

Joined: Aug 28, 2008
Posts: 82
Location: France

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

Raliegh

Posted: Nov 12, 2009 - 02:57 AM

Joined: Jan 15, 2009
Posts: 15

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

_________________
-Raliegh

Posted: Dec 02, 2009 - 10:31 PM

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

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

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

damien_d

Posted: Dec 02, 2009 - 10:44 PM

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

js wrote:

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

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.

Posted: Dec 03, 2009 - 07:52 AM

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

Quote:

Haven't touch an xplain board.

That's where I come in Smile

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

obor00

Posted: Dec 03, 2009 - 11:17 AM

Joined: Aug 28, 2008
Posts: 82
Location: France

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

damien_d

Posted: Dec 03, 2009 - 11:18 AM

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

obor00 wrote:

More the merrier.

-- Damien

david.prentice

Posted: Dec 03, 2009 - 12:06 PM

Joined: Feb 12, 2005
Posts: 16316
Location: Wormshill, England

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.

wandererwolf

Posted: Dec 03, 2009 - 06:33 PM

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

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.

clawson

Posted: Dec 03, 2009 - 06:46 PM

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

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.

_________________

Posted: Dec 03, 2009 - 09:28 PM

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

Quote:

The AVR1605 bootloader works fine on the Xplain board.

Well then, no need for me to go any further Smile

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

david.prentice

Posted: Dec 03, 2009 - 09:58 PM

Joined: Feb 12, 2005
Posts: 16316
Location: Wormshill, England

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.

bpaddock

Posted: Dec 04, 2009 - 01:57 PM

Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh

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.

Code:

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:

Code:

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

    }

Code:

#include <avr/io.h>

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

Code:

#include <avr/io.h>

#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

bpaddock

Posted: Dec 04, 2009 - 01:59 PM

Joined: Sep 27, 2001
Posts: 206
Location: North of Pittsburgh

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

Posted: Dec 04, 2009 - 09:47 PM

Joined: Mar 28, 2001
Posts: 20374
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: 62322
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: 2526
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: 2526
Location: New York State

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.

radbrad

Posted: May 10, 2010 - 05:34 AM

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

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:

Code:

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

radbrad

Posted: May 10, 2010 - 06:34 AM

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

Oops, hit submit early ... then got sidetracked ... talking on the phone and the forum at the same time...

Anyways, the above output was after changing all the settings in xboot.h, compiling, programming the bootloader, and then trying to send the main application to the bootloader. I changed your makefile to output a raw binary so AVRDude 5.10 isn't affected by the bug you mentioned, e.g. I used:

Code:

avrdude -c avrispmkII -p x256a3 -P usb -e -U boot:w:xboot.bin

Programming the bootloader to the chip hasn't been the issue (at least not since 2AM last night), the problem is sending a program to the bootloader. The bootloader I've got has verification errors, and right now yours doesn't look like it's coming out of sleep mode caused by the AVR1008 workaround.

OK, I just read all the way to the bottom of the bug you mentioned ... Maybe I'm confused, does it work OK to program it using a raw binary? Everything seems to verify OK when I do it this way ... but maybe I'm programming the boot sector wrong?

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

alex.forencich

Posted: May 10, 2010 - 06:47 AM

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

I don't think raw binary is the problem. It looks like it got programmed properly, it managed to read out the programmer ID and chip signature correctly. Looks like it got hung up in the erase routine. Odd. Unfortunately, I do not have a 256a3 to test it with, the only chip I have on a board is a 64a3. I will take a look at it, though.

The trick with the bug is that there are two separate programming commands for the flash memory. One is for the application section, the other for the boot section. When I tried AVRDude last, it couldn't program the boot section when you wrote the bootloader to either 'flash' or 'boot.' Someone submitted a fix so you could write it directly to boot and then I submitted a fix that allowed you to write it to flash by switching commands at the right point. You should be able to write a hex file, I'm not sure what writing a bin file will do. Why don't you try letting the makefile program it? You just need to change a couple of lines to tell it to use the right programmer. Actually, you probably only need to change one line (jtag2pdi to avrispmkII). Also, run a "make all" and paste the size information that shows up at the end. I want to make sure it fits in the boot section. I'm pretty sure it will, but it has less than 40 bytes to spare on my 64a3.

_________________
Alex Forencich

XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA

alex.forencich

Posted: May 10, 2010 - 06:54 AM

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

Actually, good point about AVR1008. I don't know if that has been implemented or not. Try commenting out lines 275 and 277 and see what happens.

_________________
Alex Forencich

XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA

radbrad

Posted: May 10, 2010 - 08:10 AM

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

Code:

Try commenting out lines 275 and 277

... which file? Doesn't make sense on xboot.c and xboot.h is too short.

alex.forencich

Posted: May 10, 2010 - 08:17 AM

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

Alright, I implemented the stuff in the app note. Believe it or not, for reasons unknown to me at the moment, leaving the fix active makes the code quite a bit smaller. No idea why. That compiler must be much smarter than I think it is. Hard to believe. Anyway, it does go to sleep when it writes the EEPROM on my chip. And it wakes back up afterwards. I did add a couple of lines to xboot.h and xboot.c, but most of the work was done in the EEPROM driver. Give the attached file a shot and let me know how it works. I might need to implement the flash fixes as well, but we'll take this one step at a time.

radbrad

Posted: May 10, 2010 - 08:20 AM

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

My bad, xboot.c ... I forgot I modded the file.

Nonetheless, it's more or less the same response, whether i try and erase or not.

With erase command:

Code:

$ 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

Without erase command:

Code:

$ avrdude -p x256a3 -P /dev/ttyUSB0 -c avr911 -b 38400 -D -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: reading input file "../../compucomp/Debug/compucomp.hex"

avrdude: input file ../../compucomp/Debug/compucomp.hex auto detected as Intel Hex

avrdude: writing flash (13038 bytes):

Writing |                                                    | 0% 0.00savrdude: error: programmer did not respond to command: write block

Let me know if that enlightens you any ... Maybe I'll try the AVR1008 modded code and see if I can mix and match a solution.

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

alex.forencich

Posted: May 10, 2010 - 08:41 AM

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

That does. Looks like I will need to implement the workaround for flash as well. No big deal. Also, how about we bump this discussion over to the topic dedicated to the XBoot bootloader? That seems like it would be a better place for this.

_________________
Alex Forencich

XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA

alex.forencich

Posted: May 10, 2010 - 10:47 PM

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

steve17 wrote:

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 nvours in electrical engineering. I’m currently a junior in Electrical Engineering at UC San Diego. I am heavily involved with the UCSD IEEE student org and I work on numerous independent projects outside of class.

I have been mulling over creating some sort of record of my projects for quite some time. I finally managed to talk myself into creating this blog, so from now on I will be updating it with current and past projects. My intention is for this site to be a compendium of projects and many of the little tricks that I learned while working on them. Since I already have a large portfolio of projects in various stages of completion, each project will get its own page, and the actual posting dates will be in more-or-less random order, especially for earlier projects.

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

The XBoot bootloader that I released recently will allow you to switch baud rates easily. I have tested 19200, 38400, 57600, and 115200 and they all worked perfectly. I did have to do some poking around with an oscilloscope because it didn't work properly with the calculations in the datasheet, but the "golden" values for the BSCALE and BSEL parameters for these baud rates at 2 and 32 MHz are in the header file.

Oh yeah, XBoot is AVR109 compatible, with a few XMega specific extensions (for the signature rows). That only applies to the signature rows, though. You don't need a custom program to write to the main application section.

Check it out here: http://code.google.com/p/avr-xboot/

DanielAbelko

Posted: May 18, 2010 - 06:52 AM

Joined: Sep 10, 2009
Posts: 25

I have a problem with the boot loader for large binary files. When i get to address 0x10000 the boot loader stops and says something like: "Error, no CR received from target".

I checked the source code for the xmgea boot loader and found out that the addresses is in words, i.e. two bytes. 0x10000 and higher are three bytes!

Anyone having the same problem?

KaiB

Posted: May 18, 2010 - 09:02 AM

Joined: Oct 14, 2009
Posts: 3

@DanielAbelko
see my post on 03 may. There's a new bootloader attached.

DanielAbelko

Posted: May 18, 2010 - 09:30 AM

Joined: Sep 10, 2009
Posts: 25

Thank you KaiB, but now it says:

"Unequal at address 0x20000!" :-/

Also, the file you linked me to does not contain the H-option, i.e. three byte addresses.

alex.forencich

Posted: May 18, 2010 - 10:19 AM

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

Try the XBoot bootloader: http://code.google.com/p/avr-xboot/

It has the H option and uses 32 bit addresses internally. It's very easy to configure and should work on all XMega series chips.

_________________
Alex Forencich

XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA

DanielAbelko

Posted: May 18, 2010 - 10:26 AM

Joined: Sep 10, 2009
Posts: 25

And it works together with AVROSP?

alex.forencich

Posted: May 18, 2010 - 06:14 PM

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

Haven't tried it with AVROSP, actually (I run linux). But it uses the same protocol as the AVR1605 bootloader, so I would assume that it would work. It is, however, avrdude compatible, so if AVROSP doesn't work, then avrdude should do the trick.

One thing I should point out: XBoot does not come with an AVR Studio project, so either you can build it from the command line with gcc-avr and make or you can try to import it into a new project. I would recommend building it from the command line.

_________________
Alex Forencich

XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA

CirMicro

Posted: May 18, 2010 - 07:41 PM

Joined: Jun 04, 2007
Posts: 1075
Location: Cincinnati, Ohio - USA

DanielAbelko wrote:

And it works together with AVROSP?

You could try this one that is GUI based: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=download&id=18646

DanielAbelko

Posted: May 19, 2010 - 07:43 AM

Joined: Sep 10, 2009
Posts: 25

Ok, thank you guys!

I got my to work, the problem was that i had the bootloader section filled up with rubbish in the binary file for my application. That is why i got error at address 0x20000.

kscharf

Posted: Jun 03, 2010 - 09:50 PM

Joined: Aug 04, 2004
Posts: 1822
Location: Davie, FL

xboot looks like what I need. Questions:
how do the ENTER_BLINK_COUNT and ENTER_BLINK_RATE relate to the actual delay time for a given cpu clock freq? Also my application runs at 16mhz using the pll, can I configure xboot to run at this cpu frequency to be compatible?

alex.forencich

Posted: Jun 03, 2010 - 11:58 PM

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

ENTER_BLINK_RATE determines the number of 'detect loops' XBoot runs per loop while ENTER_BLINK_COUNT determines the number of times the LED flashes. If you don't have an LED, it still runs the same code, it just skips the i/o pin update.

As for the clock frequency, I would suggest just running XBoot at 2 MHz. Your application probably sets the oscillator up properly later. 2 MHz is the most foolproof setting since it starts up in that speed by default. If you absolutely have to have it run at 16 MHz, then you will need to modify XBoot to configure the clock properly. The setting in the Makefile only affects baud rate calculations and delays.

_________________
Alex Forencich

XBoot eXtensible Bootloader for AVR ATMEGA and XMEGA

angelu

Posted: Jun 04, 2010 - 01:42 AM

Joined: May 28, 2006
Posts: 716
Location: Toronto, Canada

Quote:

2 MHz is the most foolproof setting since it starts up in that speed by default.

Not really if you want to use 115200bps.

George.

_________________
www.sofgel.ro bootloader for mega and xmega
www.elsofgel.com XME development board

kscharf

Posted: Jun 04, 2010 - 03:26 PM

Joined: Aug 04, 2004
Posts: 1822
Location: Davie, FL

The USB to serial chips we are using seem to handle the 115200 baud with the xmega at 2mhz.

I had to add a function to save and restore the uart registers or my application would not run correctly. It seems my app assumes that the chip is in reset state when entered and the usart settings left over by the bootloader are not compatible.

kscharf

Posted: Jun 04, 2010 - 04:21 PM

Joined: Aug 04, 2004
Posts: 1822
Location: Davie, FL

I've got xboot to work, but there is a big issue. Using avrdude if I download the same application hex file that was there before, OR I download the application flash space for the first time it works fine. If I replace the application space flash contents with a different hex file it fails verification and the application does not work. If I then use hyperterm to enter the bootstrap (type <esc> while the led is blinking) and then enter 'a' (to see the 'Y' and know I'm in the bootstrap) and then type 'e' to erase the flash I can then exit hyperterm and run avrdude and it will program correctly. IOW, it appears that avrdude is NOT erasing the flash first.

GCC>avrdude -p atxmega128a1 -P com3 -c avr109 -b 115200 -U flash:w:idviewcf_cancel_alert.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 = 0x1e974c
avrdude: reading input file "idviewcf_cancel_alert.hex"
avrdude: input file idviewcf_cancel_alert.hex auto detected as Intel Hex
avrdude: writing flash (54434 bytes):

Writing | ################################################## | 100% 6.81s

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

Reading | ################################################## | 100% 8.73s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0002
0x94 != 0x04
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK

avrdude done. Thank you.

clawson

Posted: Jun 04, 2010 - 04:24 PM

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

AFAIK avrdude only does an erase before program when doing ISP. It's usually up to a bootloader itself to erase pages before programming them.

Try adding a -e to the command line.

avrdude's main.c has:

Code:

      case 'e': /* perform a chip erase */

        erase = 1;

        break;

then:

Code:

  if (erase) {

    /*

     * erase the chip's flash and eeprom memories, this is required

     * before the chip can accept new programming

     */

    if (quell_progress < 2) {

      fprintf(stderr, "#s: erasing chip\n", progname);

    }

    avr_chip_erase(pgm, p);

  }

and in avr.c

Code:

int avr_chip_erase(PROGRAMMER * pgm, AVRPART * p)

{

  int cycles;

  int rc;

  if (do_cycles) {

    rc = avr_get_cycle_count(pgm, p, &cycles);

    /*

     * Don't update the cycle counter, if read failed

     */

    if(rc != 0) {

      do_cycles = 0;

    }

  }

  rc = pgm->chip_erase(pgm, p);

and butterfly.c (which implements AVR109) has:

Code:

  /*

   * mandatory functions

   */

  pgm->rdy_led        = butterfly_rdy_led;

  pgm->err_led        = butterfly_err_led;

  pgm->pgm_led        = butterfly_pgm_led;

  pgm->vfy_led        = butterfly_vfy_led;

  pgm->initialize     = butterfly_initialize;

  pgm->display        = butterfly_display;

  pgm->enable         = butterfly_enable;

  pgm->disable        = butterfly_disable;

  pgm->powerup        = butterfly_powerup;

  pgm->powerdown      = butterfly_powerdown;

  pgm->program_enable = butterfly_program_enable;

  pgm->chip_erase     = butterfly_chip_erase;

  pgm->open           = butterfly_open;

  pgm->close          = butterfly_close;

  pgm->read_byte      = butterfly_read_byte;

  pgm->write_byte     = butterfly_write_byte;

and finally:

Code:

/*

 * issue the 'chip erase' command to the butterfly board

 */

static int butterfly_chip_erase(PROGRAMMER * pgm, AVRPART * p)

{

  no_show_func_info();

  butterfly_send(pgm, "e", 1);

  butterfly_vfy_cmd_sent(pgm, "chip erase");

  return 0;

}

_________________

kscharf

Posted: Jun 04, 2010 - 04:45 PM

Joined: Aug 04, 2004
Posts: 1822
Location: Davie, FL

Thanks, that worked. I missed the -e in the help output and the -D description seemed to imply that the erase was automatic unless disabled anyway.

ala42

Posted: Jun 06, 2010 - 11:49 PM

Joined: Jun 06, 2010
Posts: 5

DanielAbelko wrote:

And it works together with AVROSP?

No, not directly. AVROSP needs an 'AVRBOOT' programmer id, xboot sends 'XBoot++', so you have to modify the id string. Also AVROSP does not send an exit command after flashing, so you have to apply a reset again or change AVROSP.

_________________
MediaCodeSpeedEdit

szaro102

Posted: Jul 23, 2010 - 02:38 PM

Joined: Feb 17, 2003
Posts: 7

Hi,
I have big problem with bootloader, everything is working fine, but when i added driver for Bootloder form AVR1316 during compilation i have error.

Code:

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../avr/bin/ld.exe: section .BOOT [00021873 -> 00021873] overlaps section .data [0002183a -> 00021841]

When i change memory settings (Project->Configuration Options->Memory Settings) to Memory Type: Flash, Name: .BOOT and Address: 0x10000 compilation is ok, but after programing CPU doesn't work. Memory usage is something about 6200B.

Maybe someone know something about .BOOT section?

I use AtXmega128A3.

clawson

Posted: Jul 23, 2010 - 05:53 PM

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

Suggest you read the Bootloader FAQ in the tutorial forum if you are writing a true bootloader rather than an app that uses some SPM functionality there is no reason on earth you would need to have a ".BOOT" section. To make a true bootloader you just use --section-start=.text=0xNNNNN where NNNNN is the bootloader address in bytes (not words!)

_________________

szaro102

Posted: Jul 23, 2010 - 07:52 PM

Joined: Feb 17, 2003
Posts: 7

I still don't konw why my Bootloader doesn't work.
I read FAQ about Bootloader, but i couldn't found any information about ".BOOT" section.
I set --section-start=.text=0x20000 ,but then bootloader compiling with error.

Code:

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../avr/bin/ld.exe: section .BOOT [00021873 -> 00021873] overlaps section .data [0002183a -> 00021841] 

clawson

Posted: Jul 23, 2010 - 08:18 PM

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

You really don't seem to understand about bootloaders. If you write a program that has both .text and .BOOT (a non-standard name created by you the programmer) with the intention of moving the functions in .BOOT to the BLS then this is NOT a bootloader. It is an application with SPM support.

In a true bootloader two completely separate programs operate within the AVR and they are built completely separately (because the bootloader code can have no reliance on anything in the app as it may not be there after a failed attempt to replace it). In this case the bootloader is built just like a normal C program with it's own vector table, own C preamble and all it's functions in the .text section but the ONLY difference between it and a "normal" app is that the entire .text (including vectors, preamble) are shifted to a new address - the BLS address.

So I suggest you remove all references to ".BOOT" from your code then try once more to relocate .text to the BLS address.

(I kind of hoped all this was clear in the FAQ that Brad and I wrote?)

_________________

andrewp

Posted: Aug 31, 2010 - 05:08 PM

Joined: Aug 15, 2010
Posts: 2

alex.forencich wrote:

Hello,

I tried your patch but patched source doesn't compile
(tried avrdude 5.10 sources and from svn repository)

jtagmkII.c:1777: error: ‘MTYPE_BOOTFLASH’ undeclared (first use in this function)

Mr. Google also doesn't known MTYPE_BOOTFLASH,
can someone give some solution for this ?

regards

clawson

Posted: Aug 31, 2010 - 05:29 PM

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

The other MTYPE_* are #defined in jtagmkII_private.h

In the avrdude 5.5 source (only one I have on my machine at present) this contained:

Code:

/* memory types for CMND_{READ,WRITE}_MEMORY */

#define MTYPE_IO_SHADOW 0x30   /* cached IO registers? */

#define MTYPE_SRAM 0x20      /* target's SRAM or [ext.] IO registers */

#define MTYPE_EEPROM 0x22   /* EEPROM, what way? */

#define MTYPE_EVENT 0x60   /* ICE event memory */

#define MTYPE_SPM 0xA0      /* flash through LPM/SPM */

#define MTYPE_FLASH_PAGE 0xB0   /* flash in programming mode */

#define MTYPE_EEPROM_PAGE 0xB1   /* EEPROM in programming mode */

#define MTYPE_FUSE_BITS 0xB2   /* fuse bits in programming mode */

#define MTYPE_LOCK_BITS 0xB3   /* lock bits in programming mode */

#define MTYPE_SIGN_JTAG 0xB4   /* signature in programming mode */

#define MTYPE_OSCCAL_BYTE 0xB5   /* osccal cells in programming mode */

#define MTYPE_CAN 0xB6      /* CAN mailbox */

Does the jtagmkII_private.h in your source not have an update on this?

EDIT: actually the "HEAD" of the current CVS is here:

http://svn.savannah.nongnu.org/viewvc/t ... iew=markup

it has some additional entries but not the MTYPE_BOOTFLASH you are searching for?!? Did you pull your avrude source from the SVN at:

http://savannah.nongnu.org/svn/?group=avrdude

_________________

andrewp

Posted: Aug 31, 2010 - 06:27 PM

Joined: Aug 15, 2010
Posts: 2

andrewp wrote:

OK, found it in AVR067, for other people, add in avrdude/jtagmkII_private.h:

#define MTYPE_BOOTFLASH 0xc1 /* xmega boot flash - documented in AVR067 */

PS.: I pulled avrdude also from svn and was missing there
PS2.: now avrdude & xboot works for me with 256a3 (buggy revision) @32MHz 115.2kbps

regards

digiman25

Posted: Sep 14, 2010 - 02:50 PM

Joined: Mar 04, 2005
Posts: 3

Was anybody able to run XBOOT with AVROSP using a XMEGA128A3? I used the AVR1008 app and made it run with GCC instead of IAR.
XBOOT is running and communication is OK, no byte is written into the flash.
Can anybody give me a hint? Thanks for help.

kscharf

Posted: Sep 14, 2010 - 05:13 PM

Joined: Aug 04, 2004
Posts: 1822
Location: Davie, FL

digiman25 wrote:

I've used xboot with avrdude (c=avr109) and it works for me.

digiman25

Posted: Sep 15, 2010 - 04:59 AM

Joined: Mar 04, 2005
Posts: 3

I can not use avrdude because I had to change communication. Now communication is fine, but XBOOT does not write to flash.

schnufff

Posted: Sep 28, 2010 - 07:56 AM

Joined: Sep 17, 2010
Posts: 2

Just a (not so) short note for the archive.
At least the avr-gcc shipped with WinAVR-20100110 seems to have a bug. I wrote my own bootloader with interrupts and everything works, except I'm unable to jump to the application. Then the device(xmega128a1 on Xplain) always hangs. When I change the BOOTRST fuse to application, the newly flashed app runs fine.
This doesn't work:

Code:

volatile void (*reset_vect)( void ) = 0x000000;

cli();

PMIC_SetVectorLocationToApplication();

EIND = 0x00;

reset_vect();

This also doesn't work:

Code:

PMIC_SetVectorLocationToApplication();

__asm__ __volatile__ (

   "cli           \n\t"

    "ldi r16,0x00   \n\t"

   "out   0x3b, r16 \n\t"

   "out   0x3c, r16 \n\t"

    "jmp 0x0000    \n\t"

   ::);

The solution:
soft reset the avr and afterwards ,depending on the reset source source, jump to app or bootloader

Code:

void check_rst_src(void) __attribute__((naked))  __attribute__((section(".init1")));

void check_rst_src(void){

   volatile void (*reset_vect)( void ) = 0x000000;

   if(RST.STATUS&RST_SRF_bm){//reset caused by software, goto APP

      //clear RST_SRF_bm

      RST.STATUS=RST_SRF_bm;

      PMIC_SetVectorLocationToApplication();

     EIND = 0x00;

      reset_vect();

   }else{//goto BL

      PMIC_SetVectorLocationToBoot();

   }

}

and then to execute the application form the bootloader

Code:

PMIC_SetVectorLocationToApplication();

   uint8_t temp = RST.CTRL | RST_SWRST_bm;

   CCP = CCP_IOREG_gc;

   RST.CTRL=temp;

   while(1);

It seems the avr-gcc init code has trouble with a unclean register state.

Hope it is useful for someone

schnufff

clawson

Posted: Sep 28, 2010 - 11:18 AM

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

Quote:

It seems the avr-gcc init code has trouble with a unclean register state

You mean machine registers R0..R31 or the SFRs? It does nothing to reset the state of the SFRs - that's the programmer's responsibility if they require it. It also makes no assumptions about R0..R31 but initialises them as it needs them.

_________________

schnufff

Posted: Sep 28, 2010 - 11:31 AM

Joined: Sep 17, 2010
Posts: 2

Quote:

It does nothing to reset the state of the SFRs - that's the programmer's responsibility if they require it.

OK, but which SFR has to be cleared before jumping into the application? I found nothing about that. All examples I found just clear EIND ( and sometimes RAMPZ) and finally jump to 0x000000. Are there any special precautions except setting the correct InterruptTableLocation ?

clawson

Posted: Sep 28, 2010 - 11:35 AM

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

Quote:

Any bootloader worth its salt will force a watchdog reset of the CPU to put every SFR back to default then it detects the MCUSR state on startup and if WDRF is set it knows it was a deliberate act and jumps to the app at 0x0000.

As you've discovered the Xmega's have a more elegant mechanism to perform such a reset - I'm pretty sure that's the way any half decent Xmega bootloader would behave to get the SFRs reset. It's either that or you have something like several hundred SFRs to individually set to default value - which isn't really practical.

Cliff

PS if this relates to some existing bootloader then I'd question it's design if it's not doing the watchdog (or Xmega) reset thing. (you may want to read the bootloader FAQ in the Tutorial Forum that I co-authored with Brad Schick: http://www.avrfreaks.net/index.php?name ... highlight=

_________________

kscharf

Posted: Sep 28, 2010 - 03:21 PM

Joined: Aug 04, 2004
Posts: 1822
Location: Davie, FL

I'm using WinAVR-20100110 and XBOOT using the
volatile void (*reset_vect)( void ) = 0x000000;
cli();
PMIC_SetVectorLocationToApplication();
EIND = 0x00;
reset_vect();
code and it seems to work fine. I suppose some applications are critical on the inital state of the CPU registers, but it would be bad coding practice to assume that the GPR are initialized to zero. I don't think GCC makes that assumption when using register variables. In any case the WDT is a good way to clear out the processor to it's init state.

clawson

Posted: Sep 28, 2010 - 04:12 PM

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

Quote:

I suppose some applications are critical on the inital state of the CPU registers, but it would be bad coding practice to assume that the GPR are initialized to zero. I don't think GCC makes that assumption when using register variables. In any case the WDT is a good way to clear out the processor to it's init state.

The real gotcha are any unhandled ??IE?? bits that are set when you sei(). For tiny/mega then WDT is the perfect way to reset the h/w. For Xmega it has a more direct mechanism to force a reset of the CPU state machine.

_________________

masoud_abbasi

Posted: Mar 13, 2012 - 12:16 PM

Joined: Jan 25, 2012
Posts: 1

hi all
i had a problem with avr1605 that when program the application code >64K with avrosp bootloader it take error unequal at address 0x10000
i fix it .the address variable has been overflow.casting was needed as wel as this------>
else if(val == 'A') // Set address...
{ // NOTE: Flash addresses are given in words, not bytes.
address = (((long int) recchar()) << Cool

| recchar(); // Read address high and low byte.
sendchar('\r'); // Send OK back.
}

kind regard
masoud abbasi fard

Jump to:

All times are GMT + 1 Hour

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

AVRFreaks.net

Search