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

Last post
142 posts / 0 new

Pages

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

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

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:

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

?

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

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.

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

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?

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

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:

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

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

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.

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

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

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

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

Quote:

 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

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

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?

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

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

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

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.

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

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

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

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.

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

@damien,

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

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

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=PNphpBB2&file=viewtopic&t=72483 . Please upgrade AVR Studio and try again.

-- Damien

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

@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?

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

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.

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

Sorry to mention, i did that change.

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

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

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

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

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

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

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

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

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

@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

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

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

Attachment(s): 

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

@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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
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

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

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

 

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

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

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

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

 

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

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:

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:

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/product_info.php?products_id=8772

Any idea what could be wrong ?

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

obor00 wrote:

The command I use to launch avrdude is:

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/product_info.php?products_id=8772

Any idea what could be wrong ?

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

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

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 ?

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

With erase option, I get a new error:

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

obor00 wrote:

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

-- Damien

Pages