View topic - New xmega Bootloader (App Note AVR1605)

Search

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

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: 20390
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: 62354
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

Jump to:

All times are GMT + 1 Hour

1, 2, 3, 4, 5 ... 8 Next All

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

AVRFreaks.net

Search