Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
damien_d
PostPosted: May 28, 2009 - 07:33 AM
Resident


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
 
 View user's profile Send private message  
Reply with quote Back to top
js
PostPosted: May 28, 2009 - 08:48 AM
10k+ Postman


Joined: Mar 28, 2001
Posts: 22236
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
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
tostmann
PostPosted: May 29, 2009 - 12:19 AM
Newbie


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
 
 View user's profile Send private message  
Reply with quote Back to top
damien_d
PostPosted: May 29, 2009 - 04:51 AM
Resident


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.
 
 View user's profile Send private message  
Reply with quote Back to top
telliott
PostPosted: May 30, 2009 - 08:14 PM
Hangaround


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

Damien,

Thanks for posting this. It just made my day a lot better.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
clawson
PostPosted: May 30, 2009 - 08:26 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 69423
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!

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
damien_d
PostPosted: Jun 08, 2009 - 12:51 AM
Resident


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.
 
 View user's profile Send private message  
Reply with quote Back to top
bpaddock
PostPosted: Jun 09, 2009 - 09:05 PM
Hangaround


Joined: Sep 27, 2001
Posts: 207
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.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
damien_d
PostPosted: Jun 10, 2009 - 09:35 AM
Resident


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.
 
 View user's profile Send private message  
Reply with quote Back to top
bpaddock
PostPosted: Jun 10, 2009 - 12:47 PM
Hangaround


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

damien_d wrote:


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.


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.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
damien_d
PostPosted: Jun 10, 2009 - 01:11 PM
Resident


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:

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.


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
 
 View user's profile Send private message  
Reply with quote Back to top
bpaddock
PostPosted: Jun 10, 2009 - 02:30 PM
Hangaround


Joined: Sep 27, 2001
Posts: 207
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.

?
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
damien_d
PostPosted: Jun 11, 2009 - 01:47 AM
Resident


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

tostmann wrote:
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


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.
 
 View user's profile Send private message  
Reply with quote Back to top
mgh148
PostPosted: Aug 26, 2009 - 02:34 PM
Rookie


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?
 
 View user's profile Send private message  
Reply with quote Back to top
bpaddock
PostPosted: Aug 26, 2009 - 06:53 PM
Hangaround


Joined: Sep 27, 2001
Posts: 207
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.
 
 View user's profile Send private message Visit poster's website 
Reply with quote Back to top
mgh148
PostPosted: Aug 28, 2009 - 06:58 PM
Rookie


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.
 
 View user's profile Send private message  
Reply with quote Back to top
mgh148
PostPosted: Sep 02, 2009 - 10:29 PM
Rookie


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;
}

 
 View user's profile Send private message  
Reply with quote Back to top
damien_d
PostPosted: Sep 02, 2009 - 11:32 PM
Resident


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
 
 View user's profile Send private message  
Reply with quote Back to top
ScottKroeger
PostPosted: Oct 08, 2009 - 02:43 PM
Hangaround


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?
 
 View user's profile Send private message  
Reply with quote Back to top
damien_d
PostPosted: Oct 09, 2009 - 12:07 AM
Resident


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
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits