Xmega128a1 self-programming avr1316

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I try to run the AVR1316 example to test self-programming.

Code is compiled in studio 6 and I have set .BOOT to .BOOT=0x010000 which generates -Wl,-section-start=.BOOT=0x20000 for the linker.

added Flash_Defines.h to #define FLASH_PAGE_SIZE 512.

I can see that the SP_CommonSPM: instruction are in the boot section.

So far, so good.

 

The issue is that SP_EraseApplicationPage(a_value_here); always erase  starting at 0x100 to 0x1FF which erase a big part of the firmware of course!

Values at address < 0x100 are probably protected, 0x1ff = 511.

 

If I track the value during execution with disassembly  everything seems fine,

Z is loaded with the correct address,

CCp protection is loaded to 0x9D in line with the define

SP_CommonSPM:

 

movw ZL, r24                    ; Load R25:R24 into Z.

sts NVM_CMD, r20             ; Load prepared command into NVM Command register.

ldi r18, CCP_SPM_gc          ; Prepare Protect SPM signature in R18             #define CCP_SPM_gc (0x9D<<0)

sts CCP, r18                      ; Enable SPM operation (this disables interrupts for 4 cycles).

spm                                  ; Self-program.

clr r1                                ; Clear R1 for GCC _zero_reg_ to function properly.

out RAMPZ, r19                 ; Restore RAMPZ register.

ret

 

 

Any suggestion why erase does not erase the page given.

 

/*! \brief Erase page at byte address in application or application table section.

*

* This function erase one page given by the byte address.

*

* \param address Byte address for flash page.

*/

void SP_EraseApplicationPage(uint32_t address);

 

Pierre

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

I don't know.

 

I did write a bootloader, and managed to get it to work.  I don't use the .BOOT = 0x010000.  I use .text = 0x010000.

 

I use assembler functions in sp_driver.s.  I notice that the SP_CommonSPM: is preceded by a commented out

;  .section .BOOT, "ax".

I assume if I want to use a BOOT section, I would have to uncomment it.  I'm not an assembler expert though.

 

I don't think addresses < 0x100 are protected, but then I'm no expert.

 


;  .section .BOOT, "ax"

SP_CommonSPM:
 movw ZL, r24          ; Load R25:R24 into Z.
 sts NVM_CMD, r20     ; Load prepared command into NVM Command register.
 ldi r18, CCP_SPM_gc  ; Prepare Protect SPM signature in R18
 sts CCP, r18         ; Enable SPM operation (this disables interrupts for 4 cycles).
 spm                      ; Self-program.
 clr r1               ; Clear R1 for GCC _zero_reg_ to function properly.
 out RAMPZ, r19       ; Restore RAMPZ register.
 ret

 

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

Thanks for answer,

commenting the .............b.oot result in the code being in FLASH but not in the boot section.

 

I read that:

Application note avr1316.pdf :

Since code that executes SPM-based commands can only run from the Boot Section, the section is most often used for bootloaders and/or parts of the application firmware that needs to update Flash memory or run other SPM-based commands.

 

And in Sp_driver.S one can read:

; Note that you must define "-Wl,--section-start=.BOOT=0x020000" for the

; linker to place this function in the boot section with the correct address.

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

Is this a bootloader with all the code in bootloader flash, or are you running code in the application flash and jumping to the bootloader to execute the SPM command?

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

steve17 wrote:

Is this a bootloader with all the code in bootloader flash, or are you running code in the application flash and jumping to the bootloader to execute the SPM command?

 

Not a boot loader, code in flash and spm command in boot section of flash, as explained in the AVR note

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

Okay, that explains the use of the BOOT section.

 

I'm not familiar with jumping back and forth between application and bootloader flash.  Before my bootloader jumps to the application it clears the CPU EIND register.  That's all I know.

 

The Xnega 128a1, as opposed to the 128a1u, has more silicon bugs than any other Xmega.  I don't know if that is your problem though.

Last Edited: Mon. Oct 19, 2015 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you use a 128a1u or a 128a1.

Can you send me the source code of your bootloader? smiley

 

Pierre

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

I only use the AU series.  The A series is obsolete.

 

I mainly use the 128a4u.

 

My bootloader uses code from various folders.  I use C++.   It would take a while to get it together.   Basically most bootloaders do things the same.  You might take a look at the bandtank bootloader that is available from github.

 

His bootloader and my bootloader both set EIND to 0 and then jump to location zero when done, to run the application.  That's the only time we touch EIND.  How the cpu fetches instructions at locations above 64k words (128k bytes) is beyond me.  I guess you know that these Xmegas have 128k bytes (64k words of instructions) of app flash.  The bootloader is above that.

 

I guess you should set EIND to 1 before jumping to the code in bootloader flash, and then set it back to 0 before jumping back to the application.  This is over my head.  I think others have applications that go over 128k on 256k Xmegas.  They would know.  Maybe the compiler has a mechanism to do this.

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

Thanks for your comments. I have discovered the EIND, but with no effect.

 

I compiled the bandtank bootloader. I will try to see how it works.

 

Pierre

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

There is definitely a bug in studio 6 simulator.

 

I have created a working bootloader serial starting from an existing bootloader which work with one of my board.

When I say working, it is because loading a short .hex file with this bootloader on the hardware, and reading back the flash  content with AVR ISP MKII tool give the same content.

 

Tracing the bootloader with values taken from the .hex file with simulator, the flash is not written with the simulator !!!!

 

Pierre

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

This is a known issue in the simulator: (http://www.atmel.com/webdoc/simu...)

"Writing/erasing FLASH using SPM and EEPROM from application not yet implemented in ATxmega devices (#7611)"

 

The reason for this is that when we make simulator model we have to replace or remove all the non-synthesizeable (analogue) parts. Flash is non-synthesizeable, which means we have to re-implement it. For xmega devices we do not have an implementation of the flash that supports SPM instructions.