We have a simple program on a SAM3U4C with a firmware update routine that runs from Flash0 with the main app running from Flash1.

I am able to write to Flash0 while running from Flash1 (from the app).

I am able to write to Flash1 while running from Flash0 (from the firmware update routine).

However, when I attempt to write to Flash0 while running from Flash0, while I can see later that the write succeeds, execution halts. This occurs not only when I write to a page in Flash, but also when I attempt to set a GPNVM bit (bit 2, for boot selecting between Flash0 and Flash1).

You're hitting yourself into the head - the flash bank is unreadable during write and your code cannot run from it. The ASF drivers have solved this by copying the core of the programming code into RAM and running from there. Of course, the code must be linked to be able to run in the RAM location.

tsvoipio wrote:You're hitting yourself into the head - the flash bank is unreadable during write and your code cannot run from it. The ASF drivers have solved this by copying the core of the programming code into RAM and running from there. Of course, the code must be linked to be able to run in the RAM location.

Thanks for your response! This is code that once ran fine on a 2C, which only has 1 Flash bank. It would have been writing to the same bank it is running from, every time. So I know the basic mechanics 'should' be OK.

To check, add the switch
-Wa,-ahlms=myfile.lst
to the GCC compilation line and read the listing.

that was it! I used this verbatim, only changing .ramcode to .ramfunc based on the naming in our linker script. I had thought I tried long_call but maybe I never did. I think that is what was missing, which seems crazy, but it is working now.