Self Programming of Dual Bank SAM4C

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

Hi folks,

 

I've done bootloaders for SAM3 and 4S and SAM4E with single bank flash, and am attempting to do one for a SAM4C32.

 

Although I can program pages of flash in the same bank, I cannot get programming from bank 1 to bank 2 to work. I think the first thing I'd like to ascertain whether I am interpreting the pages from one bank to the next correctly.

 

Bank 1 I believe has 16 sectors and within each sector 128 pages. Therefore bank 1 has 2048 pages, 0-2047. Bank 2 I think starts at 2048. However, if I attempt to erase and program pages 2048 and above, this doesn't seem to work. I am using exactly the same code to write within the same banks as I am in writing from bank 1 to 2. ie A load of setup commands are in flash, but the actual writing of commands for erase, program etc are run from RAM.

 

I am making the assumption also that in Atmel Studio if you program something into bank 2 and you select 0x1100000 in the memory window, I should be looking at bank 2.

 

I have questions about the safe and secure bootloader and how it describes two bank bootloaders, but I think it's best to ask that once this first issue is solved.

 

Many thanks.

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

Dual banked SAM4 are different. It starts with the 2 flash controllers EFC0 + EFC1 instead of a single EFC, which also needs to be used depending on the currently active bank...
I'm not sure about the memory window. The bank is selected by setting the appropriate GPNVM bit. The memory mapping remains the same regardless of the active bank.

Otherwise you couldn't run a program from one bank or the other without messing around with the linker.
I afraid, many/some debuggers don't seamless handle debugging with 2nd bank being active. I think AS can't and also Segger Ozone.
At least I had no luck to do so. Hence I ensure default 1st bank is active when debugging.

The good thing of dual-banked flash is, that no more (traditional) bootloader is needed :)

Current app flashes a new app into the other bank and switches to it (being sure, programming was fine).
Good luck !

Last Edited: Tue. Apr 7, 2020 - 12:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The EFC0 + ECF1 think is interesting. I tried compiling with that method originally and the compiler complained, so I went to just EFC and that did compile.

 

Originally the project was set up as a C16 and has migrated to a C32, so I wonder whether that has something to do with it.

 

I am using Atmel Studio with this. I don't even know what Segger Ozone is :D

Last Edited: Wed. Apr 8, 2020 - 09:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using both SAM4SD16B and SAM4SD32C. It's exactly the same except the flash size.
I afraid you didn't select the right DFP (device family pack) in AS. Doing so generates e.g. ...\sam4sd32c.h containing this

#define EFC0 ((Efc *)0x400E0A00U) /**< \brief (EFC0 ) Base Address */
#define EFC1 ((Efc *)0x400E0C00U) /**< \brief (EFC1 ) Base Address */

For single banked SAM you'll find this in the corresponding generated header:

#define EFC  ((Efc    *)0x400E0A00U) /**< \brief (EFC       ) Base Address */

Or you didn't adjust your project (include) paths to the new DFP generated files.

 

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

Are you reading out the Flash Descriptor on EFC0 to determine the Flash geometry? One of the fields indicates how many Flash planes/banks are present, so you don't need to hard-code it.

 

Steve

Maverick Embedded Technologies Ltd. Home of wAVR and Maven.

wAVR: WiFi AVR ISP/PDI/uPDI Programmer.

Maven: WiFi ARM Cortex-M Debugger/Programmer

https://www.maverick-embedded.co...

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

OK, what you say makes sense. Long, long before I got involved with this, it looks like they started with a SAMC16, then went ot the SAMC32 and although they changed the device type in AS, I am willing to bet they did not do this regeneration of the device pack and/or modify the include paths for the new DFP generated files.

 

Many thanks for the pointers, it is much appreciated. :) I may be back for clarification on how to implement necessary changes. ;-)

 

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

Thank you very much, you were right about the headers. I needed to change a preprocessor definition in the project to be __SAM4C32_0__ rather than __SAM4C16_0__

 

Does anyone know why there is sam4c32_0.h and sam4c32_1.h?

 

Similar thing going on with the C16, so I'm guessing it;s not to do with two planes.