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

142 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Attachment(s): 

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

Quote:
Atmel has (finally!) released a bootloader application note for the xmega
Must be getting real close now to releasing the Xmegas then.. :?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

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

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.

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

Damien,

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

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

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!

 

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

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.

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

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:

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

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

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.

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

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:

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

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

Quote:

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

*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

Pages