Writing to flash on the SAM E54

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

Hello all,

I'm having trouble understanding how self-programming may be implemented on a SAM processor (I'm using a SAM E54 Xplained board). I have a firmware update that I load from an SD card into RAM, and I want to overwrite the flash with that firmware.

I've looked at the flash writing example provided by Atmel START, which just has initialization code in driver_init.c and then makes a call to flash_write() to write data to the address 0x3200. I thought I could simply extended this by writing the firmware update to flash a page at a time (starting at address 0x1000 to avoid the vector table), but the code faults somewhere within flash_write().

Further research seems to suggest there's more to self-programming, but it's unclear what the other steps are. I've tried putting the flash writing code below the address 0x1000, and writing to pages beyond 0x1000, and I've tried running the update code from RAM, though there variables become corrupt (stack issues?).

Can someone help guide me towards how I may implement self-programming?

 

Edit: Looks like I somehow posted under Atmel Studio, but I can't find a way to move this thread, or delete and recreate it?

Last Edited: Thu. Feb 7, 2019 - 12:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you made any progress on self-programming?

 

We are having problems similar to what you describe with the E54, both on the E54 Xplained Pro and a custom board.

I'll update what we discover but am hoping someone has managed to make this work.

brockr

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

Yes, I figured it out at least enough for my needs.

 

These SAM processors appear to have two "banks" of flash, BANKA and BANKB, split down the middle of the flash address space. The ATSAME54P20A on the E54 Xplained Pro has a megabyte of flash, putting BANKA is at address 0 and BANKB is at address 0x80000.

The trick is that you can only write to the flash bank that you are not currently executing in. For example, running code under address 0x80000 can write flash at or above 0x80000.

For my project, I put "system code" in BANKA and "user code" in BANKB. The system code does initialization before jumping to the user code. The system code can also check for an update and flash it to BANKB.

When I write flash pages, I do a loop of flash_unlock(), flash_write(), then flash_lock().

 

Hope this helps.

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

Hello,

      im new to this microcontroller SAM E54. As you stated your able to update the firmware using SD card i'm doing same. but i want it to be standalone (no dependency on the SD card ). I have read the document about bank swapping.but can't understand it.so can you give me some suggestion on that. i want to do same as they are are suggesting i.e Bank 1 contains current running firmware while the bank 2 is updated via serial protocol frames, when update is completed & verified by CRC i want it to be switched to latest bank.

can you explained me ? what methods may used ?

 

Thanks,

Abhijeet 

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

Thanks. That makes sense now. The eeprom emulation code has "eeprom" located at 0x80000 and that seems to work.

I like the idea of avoiding bank switching as it should reduce the possibility of bricking the device due to a failed update.

brockr