View topic - New xmega Bootloader (App Note AVR1605)

Search

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

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

Author

Message

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: 62944
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: 62944
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: 62944
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: 4

alex.forencich wrote:

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

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: 62944
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: 4

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: 62944
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: 62944
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.

Jump to:

All times are GMT + 1 Hour

Previous 1 ... 4, 5, 6, 7, 8 Next All

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

AVRFreaks.net

Search