Hi,
I've heard of different mechanisms used to put an image into various locations on a demo boards memory (in my cse its a Cortex M-4 board but this may my question may be processor independent). It seems that one way is to use the scatter file. It seems to me that the linker uses this file to do the write of the image onto the memory. I was curious if it uses any particular mechanism to do this, like a memcpy or similar. I dont see this level of detail in the linker guide but was curious if anyone knows. I assume that in any linker (I am using KEIL MDK-ARM dev environment) there must be some sort of code that runs that consumes the scatter file. I also wonder what step on the way to running a user program from RAM does the actual loading. In the case of running from flash the MDK-ARM (uVision)environment has a 'Flash -> Dowload' menu item which places the program into internal flash.
One of the problems learning the details about thing like this is they are hidden from you in the development environment. I can see the scatter file and I understand it, but by which mechanism is the code actually writte to RAM?
Thanks, Dean
I did a search in the project files for some of the synbols you mentioned like __main_scatterload. I see them in the .axf and the .map files so you helped me understand that there is some code being run that I cant see (as search of the whole directory structure didnt pick up any .c or .asm files..) and that it sounds like from your explanation the code uses memcpy, etc. to move the code into the right memeory locations (in this case RAM). Also, I think you are saying the reason I cant find the actual source code is because it is in the standard library (is that what you are saying?). I was searching around about this the other day for the standard C library that keil uses in their project. I see in the option there is a choice between MicroLib and not (standard C library). Do you know if the source code exists for either of these so I could see things like code for __main_scatterload? Thanks, Dean
I haven't seen the source for __scatter.s, __scatters.s, __scatter_zi.s or __main.s, they are built into the hundreds of libraries at c:\keil\ARM\ARMCC\lib\armlib
The code is pretty evident if you turn off "Run to main()" and plod through it. It's mundane stuff but fragile.
Perhaps the headaches from them being modified is too big. This doesn't preclude you doing some pre-initialization steps for your board/hw prior to calling, and allowing the linker/crtl doing it's job. The linker hides a lot of the ugliness. If object files, linkers and loader of are interest there are CS books that likely give them pretty good coverage.
The initialization code is more obvious with GNU/GCC, and arguably less crafted.
Pretty sure fromelf, or similar tools could disassemble the Keil code.
Thanks W. Pier (I actually looked up the name and its a real Pier!),
On this subject and the other one you helped on (Boot Loader) I'm trying to gather as much info as I can before I sit down and play with the demo board. As our conversations have shown not everything that KEIL/ARM Toolchain does is readily available to look at (as you said the ugliness is hidden). Thats good and bad, good that it hides it so you dont have to deal with it but bad because you are learning the KEIL/ARM environemnt and that probably doesnt apply to IAR Embeeded Workbench, Code Composer Studio, and for other processors, etc. For instance I bet the scatter file isnt something you see used in the other dev environments (whereas you could port the source code if you had it).
I think my ultimate goal is to: * create a couple images and use a GPIO pin to boot into each one of them (simple programs that blink different sets of lights for example). I wonder if I can use a single uVision project to create 2 elf files I could load into 2 different flash locations (or ram locations). This was my reason for trying to understand how to load a program into ram (since I cant see the scatter source code I imagine I can or have to use the linker/scatter file to do this [and use other files you mentioned like the .ini). It was also my reason for trying to understand bootloader (and from our last conversation it sounds that you really end up utilizng the system bootloader as a passthrough to your IAP code which would pick from the 2 different images by reading the GPIO pin) * extend the above to run the program from close-coupled ram (as opposed to the normal 128k ram [64k reserved for close-coupled memory] or external flash (the board I'm using has both internal and external flash)
Sorry for my rambling a little! I'm sure I'll be back with more questions (and I appreciate your help and patience). Dean