Hi,

I am trying to read the 128bit unique ID stored in the sam3u flash.
There is a function in Atmel's library to do this FLASHD_ReadUniqueID();
When I use this, the code seems to block on the EFC_StartCommand(AT91C_BASE_EFC, AT91C_EFC_FCMD_STUI, 0); function call.

Does anyone have any ideas?

When fetching the unique id the code must run from sram or external sram. According to the data sheet (page 317) "Note that during the sequence, the software can not run out of Flash (or the second plane in case of dual plane)."

Thus, to solve your issue, put an __attribute__ (section(".ramfunc") )after the function. This should tell the linker that the function is to be located in sram. Make sure that the ramfunc section is part of your .relocate section that is copied from flash to ram on startup.

Looks like the __attribute__ (section(".ramfunc") ) is already included in the eefc.c file, which implements the EFC_StartCommand(AT91C_BASE_EFC, AT91C_EFC_FCMD_STUI, 0); function call.

The flash.lds file has ramfunc in the .relocate section.

Perhaps the issue is with the linker scripts?

The __attribute__ in the eefc file is dependent on #ifdef, thus I would suggest that you generate a .map file, and in your .map file make sure that the EFC_StartCommand actually has an address in internal SRAM 0x20000000 and up...

I have generated the map file and the commands appear in the following section:

.ramfunc 0x2000017c 0x108 contiki-opal.a(eefc.o)
0x2000017c EFC_StartCommand
0x20000228 EFC_PerformCommand

This should put them into SRAM0.

Is there something else required to run these commands from SRAM?

Make sure to also add the __attribute__ ((section (".ramfunc"))) before the function that calls the EFC_StartCommand, and the EFC_PerformCommand (typically FLASHD_ReadUniqueID).

The reason for this is that while you are reading the unique ID, code cannot be executed from any of the flash planes. Without the ramfunc attribute for the calling function this will not work.

Thanks for your help.

The issue was that I had a printf statement in the read unique id function, which I now know jumps you straight out of SRAM back to flash, where you can't execute any read flash commands.

Removing the printf fixed it.

It does seem a little odd that the linker script puts code at the 0x80000 address, which is where you read the unique id from.

I updated my code and remove the "Disable interrupts" commands before writing to flash, and replaced it with __ramfunc (IAR 6.21). works like a charm...
Thanks.