Scatter ext. RAM loading

Make sure your external memory buses, and devices are all properly configured in the reset path, prior to calling __main(). Review startup_yourcpu.s

Thank You Pier.
The devices are properly configured; actually I am able tu run the application if ALL the code is bootloaded and executed in external SDRAM and the scatter file doesn't include the FLASH REGION (RW_IROM1 0x0).
Now I would to bootload the whole application in external SDRAM, with the root region in SDRAM (LR_ERAM1 0xA0000000 0x00100000) but execute some modules in the internal FLASH (RW_IROM1 0x00000000 0x00010000).
I suppose this can be done, and I can compile without errors or warnings but the application doesn't run.
I am asking if it's possible to do this operation, load on external and execute on the internal (FLASH) and what are the additional requirements.
Moreover, actually I am not able to debug the application loaded on the external SDRAM.

Thanks a lot.
Paolo.

i gotta make some code for a servo motor.

what is the best project u use a servo motor for? can u send me idea and code plz.

Since _you_ gotta make some code, I would think it a bit strange to send you code. Wouldn't your teacher be a bit upset if you hand in someone else's code?

There are an infinite number of projects that could make use of servo motors. Maybe turning a potentiometer, like the volume control on an analog amplifier. Or aiming a spotlight or web camera. If the servo motor is strong enough, you could have it handle the window shutters. Or aim a squirt gun and hunt your cat :p

Yeah! damn right!

Per, what do You think about my question?
Is the situation clear enough?

Have a nice day!

Ok, if you are loading this into SDRAM, then you DON'T want to put the ROM/FLASH code within the LOAD REGION of the SDRAM, it has no mechanism to copy this into ROM/FLASH

Create TWO IROM regions, one describing the SDRAM, the other describing the ROM/FLASH region. I'm honestly not sure how you're going to make this happen in reality, because that's not how systems work. For the debugger you WILL need to create a debugger script that initializes the external bus and SDRAM so it has some place to download the code.

Normally if you had fixed code in ROM, you'd pass the linker a definition file describing the function entry points, but the ROM code wouldn't be part of the output image.

Pier I created the script, but normally I start with a bootloader. All is OK if LOAD and EXECUTION is done in the EXTERNAL SDRAM address 0xA0000000.
(I made this because of the limited room in FLASH-512K- and the idea was to load everything in SDRAM-32MB, like the LINUX project does)
Actually I was asking if "partial coming back" to FLASH/ROM after been loaded in SDRAM is possible; a sort of situation is used in IAP example, or when updating CODE in FLASH from a bootloader, the code read from USB or uSD is put in SDRAM and after rewritten in FLASH, but again, the final code is unique in one "position".
I tried to make up two separate region, according with the linker doc. (DUI0377D.pdf, using_the_linker chap. 8.5) but the compiler looks like he want to create two separate files.
I saw a similar thread about this, but still I don't face a solution, or better, I still don't understand if it's possible.

Paolo.

Pier, I didn't noted before You said "two IROM region describing SDRAM and FLASH/ROM"

Are You talking about TWO LOAD REGION FLASH BASED (0x0) one including execution regions in ext. SDRAM?
This is correct, but still get the room limitation in FLASH, that is why I was routing toward EXTERNAL RAM loading...
Thanks a lot. Again..
Paolo.

Yes, TWO IROM or ROM sections for the CODE, and TWO IRAM or RAM sections for the DATA (SRAM, and portion of SDRAM). For a 32MB SDRAM you could split the first 8MB for code, and the remaining 24MB for data.

If you can't separate your code into portions that are in ROM and those in RAM, then you will need to add some custom startup code in the ROM portion to load the SDRAM content from some kind of backing storage like a serial flash, or SD Card.

The code in ROM could call the code in SDRAM, and the code in SDRAM could call the code in ROM. All the linkage is provided by the linker. Getting the code/data into the right place is the job of a LOADER.

The linker will generate a .HEX or .AXF(ELF) file, and you will need to post-process that into the image that goes directly into the flash within the part, and a file containing the code to be loaded into SDRAM. For example you could burn the ROM part of the .HEX to FLASH, and then store the whole .HEX on an SD Card, and then using ROM based code to load and parse the .HEX file and place the SDRAM bound data there, after that memory has been initialized.

This might be better implemented in a small boot loader, perhaps ~16KB, with code to initialize SDRAM and support a file system on an SD Card. It could load the SDRAM bound code, and jump to the entry point of the ROM application.

Actually this was the first idea (and the first release), and in some part is already working; I have a .BIN file created from the AXF that is bootloaded in FLASH by a quite larger bootloader (~40K) but I went out of space in FLASH.
After that would like to place ALL in SDRAM, the same way plus MPU etc etc but got speed issues.
So I thought to separate regions, and first idea was to use a "double" bootloader, quite the same as your solution, to load separate modules, just like an OS.
The hope, was to be able to let the linker do the dirty job by a special crafted scatter file, but docs and threads let a dark region about separating ROM/RAM (INT/EXT).

Anyway, Pier I really wish to tank You for the time spent.
I'm still investigating...

In your model, how do you plan on storing and delivering the code/data you need into the SDRAM at start up?

The other thing that is done for speed is to create a ROM (mask level, in my case) with a lot of the library, and standard functions. There is a clear abstraction, and the linker imports these like external library calls via a definition file. The code never gets into the other RAM/FLASH based code, it just calls out the the addresses specified.

This is a bit like the model used by Stellaris to ROM CRC/AES functions and tables.

The linker can do a lot of the dirty work, but the Load Region might not be the way to go, as it infers a container from which other volatile memory area have their data/code/statics copied from. And you can't copy data out of a region into a Read Only memory. The idea is to be in Read Only memory and copy out each time the code starts.

As noted, a small boot loader in flash that loads in a program from a SD card can't/shouldn't make use of any flash space. It is a bit strange situation to have a small boot loader use IAP to flash parts of the loaded application (which would require CRC-32, MD-5, full content compare or similar to make sure the flash only gets reprogrammed after a change of the binary on the SD card) while copying the rest into DRAM.

It would be more logical if the SD card contained two image files.

One (optional) image file represents a "BIOS" update with help code that should be IAP-stored into flash and run there.

One image file represents the actual application that is 100% copied into RAM - potentially splitted between SRAM and DRAM if the processor supports it and can make use of higher SRAM execution speeds.

And the actual application then either uses a pointer table or is hard-linked to make use of functions within the flash region. Hard-linking would then require that the boot loader only accepts a situation where the two image files have a matching version, while the use of a pointer table would remove the need for the "BIOS" and application to have lock-step version releases.

But the scatter load files can't be used to distribute code from RAM into flash because the scatter loading is performed by help functions within the Keil library - and this code assumes that the scatter loading can be done with normal memcpy() while flash updates require special code. So any code to run in the flash must be stored there from factory or by some code you write that can perform IAP to refresh the flash content.

If the functions accessible from flash isn't required for the startup of the application, then the IAP code to verify the contents of the flash and optional update of the flash region from an SD file could be inside the DRAM-run code loaded from SD instead of in the boot loader. This allows the boot loader to be smaller and simpler. So the boot loader just loads a file from SD into DRAM and starts the program and custom code in the application then checks for a second SD file and verifies if it needs to be written to flash before making use of the pointer table to start to access flash code.

Pier and Per, those are realistic expansions of what I was thinking about; a sort of kernel loaded and run in FLASH/ROM, stored on SD card and IAP-ed when needed (update time) AND a second "layer" usually taken from SD card and stored at BOOT-time in EXT.SDRAM (INT SRAM if necessary for speed issues). Maybe first layer more a Bios than a Kernel, as noted.
This requires a bit more time to be spent analyzing the structure of the code originally born to be loaded or flashed whole in a single region, in FLASH.
I'll keep this thread updated soon as I'll have updates.
Fell free to contribute!

Again, Thanks a lot to everyone, a great job is done in this forum.

Paolo.