Hi
I am using LM3S9B96 evaluation board and FLASH/SRAM/LCD IF external board. IDE: CrossStudio for ARM 2.0
How to generate the binary files which are located partly in the internal memory (flash&sram) and partly in the external memory(external flash & sram)? And is there any examples on the LM3S9xxx processors to do that?
I was able to get the modified blinky example running from external flash, but can not figure out how to generate code for both internal and external and running the main application in internal memory.
Thanks!
We do not have any examples for setting up applications to run from both internal memory and external memory on the EPI interface. The difficulty would be getting the toolchain to generate two separate binary images, one to be loaded into internal memory, using standard tools, and the other to be loaded into the external memory, using a loader app running on the device. Each toolchain supported (e.g. Keil, IAR, etc.) would need to be configured differently.
If you need to run code from external memory, I would recommend writing the code for the external memory as a library, with a function table located at the beginning of the memory. You would then simply need to write a header file that maps "function names" to the appropriate lookup table in the external memory. This would be similar to what has been done with DriverLib API's that have been placed into ROM. You could refer to the "rom.h" header file for more details about how this was implemented.
This would remove the direct link between the main application in internal memory and the functions residing in external memory and simplify the build process.
--Bobby
Thank you for your help Bobby!
Sounds like building the external code as library is much easier than struggling with the toolchain.
In my understanding, the procedure should be :
1:Write the code for external memory as a library and generate the binary image.
2.Modify the "boot_eth_ext" demo to load the binary image which is generated in step1 to external flash/sarm, and NOT running from external flash.
3.Write the main application code with the mapping files to lookup table in the external memory.
4.Erase the internal memory (where the bootloader reside in) before loading the main application binary image.
5.Load the internal binary image.
Is the above procedure sounds correct and practical? Thank you!
That process sounds correct. As always, the details will probably be more involved, but it should get you going in the right direction.
Bobby, you are right, there are always more details involved.
I tried to build a application for the external flash which just toggle the LED. And my main application in the internal flash will call the EXT_ToggleLED( ) function just like calling a ROM_ function. But it keeps falling into Fault_ISR( ).
#define EXT_LEDTESTTABLE ((unsigned long *) 0x60000320) // 0x60000320 is where the linker placed the EXT_ToggleLED( ) function into external flash
#define EXT_ToggleLED ( (void (*) ( ) ) EXT_LEDTESTTABLE)
I am not sure the above way that linking the external function is correct and I guess I must missed something when building the external "library" binary image. Do you have any documents or suggestion on building the ROM_ like binary image for the external memory and relate it to the internal caller function? Thank you! Appreciated!
-Tekkon
Bobby,
I finally succeed in toggling a led in the external flash just like calling a ROM_ function.
From the generated memory map file of external application, the actual address of the EXT_ToggleLED( ) function in external memory is 0x600002D4. But I have to define EXT_ToggleLED ((void(*)( )) 0x600002D5) in my internal main application, otherwise, it will keep falling into ISR if I use 0x600002D4. Still do not understand why the address branch to is always the true address plus one ? I checked the ROM_ like function, they are doing the same thing.
The least significant bit of the instruction address is the processor mode to execute the instruction in. The Cortex-M3/M4 only operate in the extended Thumb instruction mode, and do not support 32 bit ARM instructions (except for those included in the extended Thumb instruction set).
slandrum,
Thank you for your help. By following what you posted, I did a little research. The blx instruction can change the processor state, either from ARM to Thumb, or from Thumb to ARM. The bit[0] of the instruction address is 1, just means the processor changes to, or remains in Thumb mode.