Go Down

Topic: Arduino DUE Memory Hierarchy (Read 2597 times) previous topic - next topic

inkspell4

Mar 24, 2016, 09:06 pm Last Edit: Mar 24, 2016, 09:43 pm by inkspell4
I have looked at the Arduino DUE documentation as well as the ATSAM3X documentation and cannot find anywhere where the location of the code and bootloader are specified. Is this information anywhere that can easily be accessed?

Specifically I am looking for what is stored where in the flash and how to utilize the other portions of flash as well as the use of the embedded SRAM;

westfw

#1
Mar 26, 2016, 07:12 am Last Edit: Mar 26, 2016, 07:13 am by westfw Reason: linked in image
Quote
cannot find anywhere where the location of the code and bootloader are specified.
When in doubt, go all the way back to the Atmel Datasheet.

The SAM3X chips have their bootloader in ROM (probably actually uneraseable flash), and it's utilized by mapping that memory into the flash address space that normally starts at 0x0.  Following that is all of the flash in the chip, starting at 0x80000.  (If you disassembly a Due program, you'll find that it starts at 0x80000)  

There are two banks of RAM, one (64k) at 0x20000000 and the other (32k) at 0x20080000.

You shouldn't normally need to do anything to "utilize" the sections; the linker and library should do all of that work for you,if your program gets big enough to need them.


inkspell4

I was able to decipher that much, the problem I found is that there is no definition of where the user can manipulate data in flash, and or what information is stored in SRAM.

I am attempting to make a program to test the memory on the chip and are running into issues with overwritting the program in both the SRAM and Flash blocks.

westfw

Beyond the normal C variables like _etext, _end, and _estack ?
For testing RAM from a C program, you'd normally allocate a good-sized chunk with malloc(), and run your tests on that segment.  Or use a local array (on the stack.)


inkspell4

But that would only test part of the RAM? and what about the flash?

westfw

If the part of RAM that you are using in bad, your test code isn't likely to run reliably anyway...
Is this for some stanards requirement like IEC60730 or IEC61508?  If so, you should probably look at ap notes from the CPU manufacturers, or buying code from someone who has done it already.  If not... please explain exactly what you want your tests to accomplish...

The products I actually worked on (which did NOT conform to any particular standard that I know of) would run RAM self-test in early startup code (before starting to use RAM), and checked a CRC in the used ROM/Flash/etc for basic sanity.  They didn't use the flash beyond the actual code, so that wasn't tested at all, except when loading it up with new code/etc (and again using a CRC and/or checking for failures during write.)


inkspell4

Specifically, it is part of a functional test of the ATSAM3X8E hardware. I have been able to read the SRAM and go through it all, but when testing the write functionality I always run into the problem of overwriting some part of my program and or having the program stall. That being said I have not found a way to test the Flash.

inkspell4

#7
Apr 02, 2016, 08:45 pm Last Edit: Apr 02, 2016, 10:15 pm by inkspell4
I am now trying to figure out if my boundaries are set correctly.

My current boundaries for testing are :

 uninit_data_end = (uint32_t) &_end;
 
  int v;
  free_sram_end =  (int) &v;

but I am running into a problem in that I am not sure those boundaries are correct due to finding a set area of memory that is either untouchable or has actually failed. I get the boundaries in the setup and then use them in the loop. Is this a problem?

inkspell4

I was able to get the test to pass the board by moving the definition of the boundaries into the test function instead of being in setup()

Now to move on to the flash. Does anyone have any tips on finding the boundaries of the non-program flash and/or tips on accessing without using any additional libraries.

westfw

Flash on Due is just in the normal address space, as far as reading.
Writing requires talking to the "Enhanced Embedded Flash Controller", but keep in mind that there is a  limit on the number of times you can write to flash memory, so you really don't want to do a write test each time you power on.

inkspell4

It is a one off test program, and in that case do you have any tips regarding the Enhanced Embedded Flash Controller other than what is in the datasheet?

Go Up