Erase application section not working for me...

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

I'm using an atxmega384c3 and have a bootloader that is able to erase/write flash pages just fine.  The command that is supposed to erase the entire application section however does not work.

 

This test code first programs a page with the values 0x01 and then is supposed to erase the application memory.  When I read back the flash it is 0x01 and NOT erased showing that the SP_EraseApplicationSection() function does not work as expected.

    memset(buff3,0x01,512);
    
    SP_LoadFlashPage(buff3);

    //program the flash
    SP_EraseWriteApplicationPage(0);
    SP_WaitForSPM();



    SP_EraseApplicationSection();
    SP_WaitForSPM();


    PORTE.DIRSET=_BV(5);
    PORTE.OUTCLR=_BV(5);

    for(;;);

I am using a sp_driver.s and sp_driver.h and I've modified it to add some functions that were not in the original files I found here.  Here are the relavant cuts of code for this issue:

 

#define NVM_CMD_ERASE_APP_gc (0x20<<0)	// Erase Application Section

.section .text
.global SP_EraseApplicationSection

SP_EraseApplicationSection:
	in	r19, RAMPZ                 ; Save RAMPZ, which is restored in SP_CommonSPM.
	ldi	r20, NVM_CMD_ERASE_APP_gc  ; Prepare NVM command in R20.
	jmp	SP_CommonSPM               ; Jump to common SPM code.

.section .text, "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

The datasheet says something about:

 

28.11.2.7 Erase Application Section
The erase application command is used to erase the complete application section.
1. Load the Z-pointer to point anywhere in the application section.
2. Load the NVM CMD register with the erase application section command.

3. Execute the SPM instruction. This requires the timed CCP sequence during self-programming.

 

So I did wind up trying to use clr r24, and clr r25 in the SP_EraseApplicationSection section before it jumps to the SP_CommonSPM, but this did not seem to make any difference.

 

Any thoughts or ideas on what to try next?

 

Thanks,

 

Alan

 

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

Is there anything in the errata? This command didn't work on the E5, but I thought other models were okay.

 

Do you have an ammeter in your power supply loop, or a weak supply or something? That, especially with brown-out protection enabled, can cause it to fail.

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

Hi Mojochan!

 

The only thing mentioned by the errata is "Temperature sensor not calibrated".

 

Power supply should be good; it is on a finished product/board that is rock solid.

 

I find it peculiar that the EraseWriteApplicationPage works 100% of the time.

 

Thanks,

 

Alan

 

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

Your code is identical to mine, which works on other parts. The next usual suspect is that your .text section isn't at the right location for your part, but since you can write app section pages that seems unlikely.

 

Might be time to contact Atmel, looks like it could be a bug. As a work-around you can do what we have to do on the E5 and erase page-by-page.

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

I'm sure I've read a thread about this before and not concerning E5. So I'm pretty sure there's been prior traffic about this.

 

I think the conclusion there was that the chip cannot possibly be erasing pages in parallel as it requires an internal voltage boost and it couldn't be doing that to all the pages in parallel. So presumably "erase app section" just operates internally as a "for n=0 .. N_app_pages; erase page n" anyway? So it could be that there's not a lot to be gained by its use anyway?

 

Or does experimentation where it works prove otherwise? Does it really erase all the pages in the same time as just one when it works?

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

The bootloader is located at 0x60000.

 

I've also got a XMEGA64A4U on the board I need to do this with as well - I'll try the command on it and see if it can do it.

 

Do you think the Z pointer has to be cleared or set somewhere within the application area like the datasheet suggests?  It gets copied from r24/r25 in the SP_CommonSPM.  I did try clr r24 and clr r25 but it didn't make a difference.  That would only be 64K - do you think the RAMPZ needs to be cleared???

 

I guess I wonder if it can do an entire erase on only the application section leaving the bootloader section alone.  I'm not sure how the chip erase works at a hardware level vs. just one page.

 

I agree that I could do it with a loop and if this can't be figured out that will have to be the method.

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

Cliff, the datasheet gives the page erase type as typically 4 seconds. There are 768 pages in the app section so a little over 3000ms for a full erase. Chip erase takes 130ms, so somehow it's a lot faster. Not all-at-once fast, but maybe it does batches of 24 or 32 pages at 4ms each or something.

 

alank2, your bootloader should be at 0x15000 I believe. It's the byte address (0x30000) divided by 2 for word addressing.

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

Hi Mojochan,

 

The bootloader is located directly after the 384K application section.  Word addressing = 0x30000, byte addressing = 0x60000.  In AS7 for the linker you have to put in the byte address.

 

I appreciate the tip though - the word/byte addressing has gotten me multiple times before! :)

 

Thanks,

 

Alan

 

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

Sorry, I'm being a plank. It should be 0x30000. Confusing, as you say. 0x60000 is probably wrapping around but maybe it's messing something else up. Try 0x30000.

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

It'll depend how you specify it in AS7.

 

If you use their "Memories" tab of the project config then they'll want you to enter ".text=0x30000" and it will be converted to a -section-start=.text=0x60000 when passed to the linker because, as that long winded comment in that dialog says, they take an Flash address entered and double it.

 

However if you are entering it manually yourself as -Wl,-Ttext=0x60000 or -Wl,-section-start=.text=0x60000 then in those case you should use the 0x60000 number not 0x30000.

 

(life would be a whole lot simpler if everyone just agreed to address all memory in terms of byte addresses!)

 

Atmel kind of dug a hole for themselves when they first started talking about Bootloader addressing in their datasheets and did it all in terms of 16 bit word addressing because that is the opcode granularity.

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

I put it in manually under toolchain -> avr/gnu linker -> miscellaneous:

 

-Wl,--section-start=.text=0x60000 -nostartfiles

 

It shows up at 0x60000 in the LSS file which I think it all byte addressing...

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

Yup, that all sounds right then.

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

In that case you should perhaps contact Atmel. The fact that the '384 has its own datasheet and a larger memory than any of the known working devices suggests that the NVM controller might have undergone some revisions and broken the chip erase. If they managed to do it on the E5, maybe they managed to do it here too.

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

UPDATE : initializing the RAMPZ to 0 FIXES the issue.

.section .text
.global SP_EraseApplicationSection

SP_EraseApplicationSection:
	in	r19, RAMPZ                 ; Save RAMPZ, which is restored in SP_CommonSPM.
	out	RAMPZ,0
	ldi	r20, NVM_CMD_ERASE_APP_gc  ; Prepare NVM command in R20.
	jmp	SP_CommonSPM               ; Jump to common SPM code.

 

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

Thanks alank2. I will try to find time to test that on a 256k part as well, see if it is specific to the larger memory.

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

Has anyone had time to check/test this further or has there been any news on it since lat year?  I ran into it again with my new code that initializes RAMPZ to 0, issued the command, got a response back that it was done, but checking the flash = NOT DONE.