SAME54 xplained pro with Atmel Start persistent storage

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

I've created a project for the SAME54 xplained pro board and I'm trying to figure out how to configure the persistent storage module because I'd like to use the internal flash memory space instead of using an external eeprom.

 

Using atmel start I added the flash driver and the persistent storage middleware, but I'm trying to figure out how to configure it.  The defaults in the Internal Flash persistent storage configuration settings shows that the Storage start address =65536, sector size=4096, Item number=10.

 

When I hit generate project, Atmel start generates persistent_storage_start.c/h files with examples that don't work.  I'm not really surprised because I see the item number is 10 in the default settings and the example is using 1.  Also, I'm not certain about the start address that is being used?  Does anyone have an idea as to what it should be?   Also the example has a comment mentioning an entry in the linker script, Atmel start didn't seem to do that and I'm not clear on how to add it.  I'm hoping someone may have done this and can provide some help with the correct addresses and/or procedure on how to get the NVram integrated.

 

Any help is greatly appreciated.

 

  

/**

* \brief Persistent storage example

*

* IMPORTANT! Be careful running this example. It makes assumption that storage

* area provided in Persistent storage configuration is reserved in the linker

* script. If it is not reserved, flash content may get corrupted.

*/

void persistent_storage_example(void)

{

// store, read and eraze one item

uint8_t data[10];

memset(data, 0xa5, 10);

nv_storage_write(1, 0, data, 10);

memset(data, 0x00, 10);

nv_storage_read(1, 0, data, 10);

nv_storage_delete(1);

}

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

Hi, the persistent storage "User Guide" in Atmel Start leaves quite a bit for the user to figure out...

 

The sector size must be chosen as a multiple of your microcontroller's flash row size, see its datasheet. Looking at the driver code, each sector contains a header of 24 bytes size, and each item has a header of 14 bytes, so adding that to the size of your configuration data, and adding a few bytes to account for alignment, will give you an idea whether the sector size you chose is big enough.

 

For straightforward uses just a single "item" (i.e. block of configuration data) would be needed. If you don't actually write to more than one item, I think it does not matter if the maximum item number configuration is left at 10.

 

The persistent storage driver uses two sectors by default, so you have to set aside the corresponding amount of flash memory.

 

For example, I am using an ATSAMD21E16 which has 64kB main flash ROM with row size of 256. I just needed a small amount of configuration data, so I chose sector size = 256 which means the amount of flash memory used by the driver is 512 bytes. In the linker file Device_Startup/samd21e16b_flash.ld I just changed the length of the ROM section from LENGTH = 0x00010000 to LENGTH = 0x0000FE00. This should ensure the linker doesn't place any program code after adress 0xFE00. This is then also the Storage Start address to configure for the persistent storage.

 

Finally, I ran into a bug in the driver, where a spurious call to nv_read() (in nv_internal_flash_ultra.c) is done beyond the end of the flash ROM. Commenting out the ASSERT statement in that function is a workaround. Persistent storage appears to work now, although I haven't tested extensively yet.

 

Update: although it works the first time, it doesn't when the configuration is written a second time... a problem is that the Persistent Storage driver intends to offer much more flexibility than I actually need, and the resulting complexity makes it difficult to understand what's going on in it. At this point I'm considering to implement my own EEPROM emulation using some of the lower level functions in the driver.

 

Best regards
Simon Brouwer

Last Edited: Thu. Apr 12, 2018 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the response to this, with your explanation I have a much better understanding.  In addition to posting here, I also opened a case with Microchip support and they mentioned that they were aware of the problem with the NVM persistent storage driver and they recommended that we use the flash driver calls directly. 

 

Which we did and I found a way to use it for single byte access; Where BASE_FLASH_ADDR is above program space and data is uint8_t.  It seems to work OK for our application.

flash_write(&FLASH_0, (BASE_FLASH_ADDR+addr), data, 1); 

 

Our project is not finished yet, but I the way I chose the BASE_FLASH_ADDR was to program the device and read it back with Atmel studio and store it to a file.  I located the end of the application space and picked a page size boundary far above the end of the application.  Seems to be OK for now, but I agree that the linker file will have to modified to protect that space.  We also have an added complexity with the SAM-BA bootloader that needs to be considered and I'm not sure how to handle that yet.  As I started to look into the code for that, I see that the application start address is clearly defined but I need to figure out how to set the application end address.  Would you happen do have any hints for that?

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

how to update winc1500 certificate from same54 microcontroller

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

i just came across this question today (may be late by an year :-P) but reply can be useful for others...

 

i believe E54 device has smart EEPROM support in hardware. So no need for persistent storage software support.. device like SAMD21 will need this persistent storage solution...

whoever needs similar thing can look for smart eeprom example in Atmel START...