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

Go To Last Post
143 posts / 0 new

Pages

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

Oops, hit submit early ... then got sidetracked ... talking on the phone and the forum at the same time...

Anyways, the above output was after changing all the settings in xboot.h, compiling, programming the bootloader, and then trying to send the main application to the bootloader. I changed your makefile to output a raw binary so AVRDude 5.10 isn't affected by the bug you mentioned, e.g. I used:

avrdude -c avrispmkII -p x256a3 -P usb -e -U boot:w:xboot.bin

Programming the bootloader to the chip hasn't been the issue (at least not since 2AM last night), the problem is sending a program to the bootloader. The bootloader I've got has verification errors, and right now yours doesn't look like it's coming out of sleep mode caused by the AVR1008 workaround.

OK, I just read all the way to the bottom of the bug you mentioned ... Maybe I'm confused, does it work OK to program it using a raw binary? Everything seems to verify OK when I do it this way ... but maybe I'm programming the boot sector wrong?

_________________
Brad Nelson
http://bradsprojects.wordpress.com

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

I don't think raw binary is the problem. It looks like it got programmed properly, it managed to read out the programmer ID and chip signature correctly. Looks like it got hung up in the erase routine. Odd. Unfortunately, I do not have a 256a3 to test it with, the only chip I have on a board is a 64a3. I will take a look at it, though.

The trick with the bug is that there are two separate programming commands for the flash memory. One is for the application section, the other for the boot section. When I tried AVRDude last, it couldn't program the boot section when you wrote the bootloader to either 'flash' or 'boot.' Someone submitted a fix so you could write it directly to boot and then I submitted a fix that allowed you to write it to flash by switching commands at the right point. You should be able to write a hex file, I'm not sure what writing a bin file will do. Why don't you try letting the makefile program it? You just need to change a couple of lines to tell it to use the right programmer. Actually, you probably only need to change one line (jtag2pdi to avrispmkII). Also, run a "make all" and paste the size information that shows up at the end. I want to make sure it fits in the boot section. I'm pretty sure it will, but it has less than 40 bytes to spare on my 64a3.

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

Actually, good point about AVR1008. I don't know if that has been implemented or not. Try commenting out lines 275 and 277 and see what happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Try commenting out lines 275 and 277

... which file? Doesn't make sense on xboot.c and xboot.h is too short.

_________________
Brad Nelson
http://bradsprojects.wordpress.com

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

Alright, I implemented the stuff in the app note. Believe it or not, for reasons unknown to me at the moment, leaving the fix active makes the code quite a bit smaller. No idea why. That compiler must be much smarter than I think it is. Hard to believe. Anyway, it does go to sleep when it writes the EEPROM on my chip. And it wakes back up afterwards. I did add a couple of lines to xboot.h and xboot.c, but most of the work was done in the EEPROM driver. Give the attached file a shot and let me know how it works. I might need to implement the flash fixes as well, but we'll take this one step at a time.

Attachment(s): 

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

My bad, xboot.c ... I forgot I modded the file.

Nonetheless, it's more or less the same response, whether i try and erase or not.

With erase command:

$ avrdude -p x256a3 -P /dev/ttyUSB0 -c avr911 -b 38400 -e -U flash:w:myprogram.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 = 0x1e9842
avrdude: erasing chip
avrdude: butterfly_recv(): programmer is not responding

Without erase command:

$ avrdude -p x256a3 -P /dev/ttyUSB0 -c avr911 -b 38400 -D -U flash:w:myprogram.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 = 0x1e9842
avrdude: reading input file "../../compucomp/Debug/compucomp.hex"
avrdude: input file ../../compucomp/Debug/compucomp.hex auto detected as Intel Hex
avrdude: writing flash (13038 bytes):

Writing |                                                    | 0% 0.00savrdude: error: programmer did not respond to command: write block

Let me know if that enlightens you any ... Maybe I'll try the AVR1008 modded code and see if I can mix and match a solution.

_________________
Brad Nelson
http://bradsprojects.wordpress.com

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

That does. Looks like I will need to implement the workaround for flash as well. No big deal. Also, how about we bump this discussion over to the topic dedicated to the XBoot bootloader? That seems like it would be a better place for this.

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

steve17 wrote:
I don't know what the differences are between Xmegas. I thought they were similar. Damien's port with the fix in my above post works fine on my 128a1. The only things I changed, other than those in the above post, were some configuration changes in defines.h.

You need to change 7 lines in UART control to specify the registers of the USART you are using. All the nvours in electrical engineering. I’m currently a junior in Electrical Engineering at UC San Diego. I am heavily involved with the UCSD IEEE student org and I work on numerous independent projects outside of class.

I have been mulling over creating some sort of record of my projects for quite some time. I finally managed to talk myself into creating this blog, so from now on I will be updating it with current and past projects. My intention is for this site to be a compendium of projects and many of the little tricks that I learned while working on them. Since I already have a large portfolio of projects in various stages of completion, each project will get its own page, and the actual posting dates will be in more-or-less random order, especially for earlier projects.

Alex Forencichames that don't end with BIT need to be changed, unless you are using the same USART as Damien. You also need to change 3 lines in "pin for entering self prog mode".

If you have a system clock of 2 MHz and are running at 9600 baud, you don't need to change the baud rate stuff. Beware of the "#define BAUD_RATE 9600" line. It does nothing and should be removed. It's the BRREG_VALUE that sets the baud rate, and it sets it for 9600 baud.

If you want to run faster, I made a few changes that let me also run at 38400 or 115200 baud. I use the BSCALE to let me run at these speeds with a user-unfriendly 2 MHz system clock. I can post my changes if you want.

What programming program are you running on the PC? As far as I can figure out, only avrdude will do the job on Windows. I use the "-c avr911" option.

The XBoot bootloader that I released recently will allow you to switch baud rates easily. I have tested 19200, 38400, 57600, and 115200 and they all worked perfectly. I did have to do some poking around with an oscilloscope because it didn't work properly with the calculations in the datasheet, but the "golden" values for the BSCALE and BSEL parameters for these baud rates at 2 and 32 MHz are in the header file.

Oh yeah, XBoot is AVR109 compatible, with a few XMega specific extensions (for the signature rows). That only applies to the signature rows, though. You don't need a custom program to write to the main application section.

Check it out here: http://code.google.com/p/avr-xboot/

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

I have a problem with the boot loader for large binary files. When i get to address 0x10000 the boot loader stops and says something like: "Error, no CR received from target".

I checked the source code for the xmgea boot loader and found out that the addresses is in words, i.e. two bytes. 0x10000 and higher are three bytes!

Anyone having the same problem?

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

@DanielAbelko
see my post on 03 may. There's a new bootloader attached.

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

Thank you KaiB, but now it says:

"Unequal at address 0x20000!" :-/

Also, the file you linked me to does not contain the H-option, i.e. three byte addresses.

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

Try the XBoot bootloader: http://code.google.com/p/avr-xboot/

It has the H option and uses 32 bit addresses internally. It's very easy to configure and should work on all XMega series chips.

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

And it works together with AVROSP?

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

Haven't tried it with AVROSP, actually (I run linux). But it uses the same protocol as the AVR1605 bootloader, so I would assume that it would work. It is, however, avrdude compatible, so if AVROSP doesn't work, then avrdude should do the trick.

One thing I should point out: XBoot does not come with an AVR Studio project, so either you can build it from the command line with gcc-avr and make or you can try to import it into a new project. I would recommend building it from the command line.

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

DanielAbelko wrote:
And it works together with AVROSP?

You could try this one that is GUI based: https://www.avrfreaks.net/index.php?name=PNphpBB2&file=download&id=18646

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

Ok, thank you guys!

I got my to work, the problem was that i had the bootloader section filled up with rubbish in the binary file for my application. That is why i got error at address 0x20000.

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

xboot looks like what I need. Questions:
how do the ENTER_BLINK_COUNT and ENTER_BLINK_RATE relate to the actual delay time for a given cpu clock freq? Also my application runs at 16mhz using the pll, can I configure xboot to run at this cpu frequency to be compatible?

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

ENTER_BLINK_RATE determines the number of 'detect loops' XBoot runs per loop while ENTER_BLINK_COUNT determines the number of times the LED flashes. If you don't have an LED, it still runs the same code, it just skips the i/o pin update.

As for the clock frequency, I would suggest just running XBoot at 2 MHz. Your application probably sets the oscillator up properly later. 2 MHz is the most foolproof setting since it starts up in that speed by default. If you absolutely have to have it run at 16 MHz, then you will need to modify XBoot to configure the clock properly. The setting in the Makefile only affects baud rate calculations and delays.

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

Quote:
2 MHz is the most foolproof setting since it starts up in that speed by default.

Not really if you want to use 115200bps.

George.

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

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.

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

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

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

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:

      case 'e': /* perform a chip erase */
        erase = 1;
        break;

then:

  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

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:

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

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

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

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.

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

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.

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

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.

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.

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

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

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

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.

c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../avr/bin/ld.exe: section .BOOT [00021873 -> 00021873] overlaps section .data [0002183a -> 00021841] 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

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: https://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

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

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:

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

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

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

andrewp wrote:

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

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

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

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.

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

digiman25 wrote:
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.

I've used xboot with avrdude (c=avr109) and it works for me.

Attachment(s): 

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

I can not use avrdude because I had to change communication. Now communication is fine, but XBOOT does not write to flash.

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

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:

volatile void (*reset_vect)( void ) = 0x000000;
cli();
PMIC_SetVectorLocationToApplication();
EIND = 0x00;
reset_vect();

This also doesn't work:

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

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

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

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

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.

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

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 ?

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

Quote:

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 ?

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: https://www.avrfreaks.net/index.p...

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

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.

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

Quote:

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.

The real gotcha are any unhandled ??IE?? bits that are set when you sei(). For tiny/mega then WDT is the perfect way to reset the h/w. For Xmega it has a more direct mechanism to force a reset of the CPU state machine.

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

hi all
i had a problem with avr1605 that when program the application code >64K with avrosp bootloader it take error unequal at address 0x10000
i fix it .the address variable has been overflow.casting was needed as wel as this------>
else if(val == 'A') // Set address...
{ // NOTE: Flash addresses are given in words, not bytes.
address = (((long int) recchar()) <<8)| recchar(); // Read address high and low byte.
sendchar('\r'); // Send OK back.
}

kind regard
masoud abbasi fard

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

SPAM removed

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

Pages

Topic locked