I've been browsing the uVision/MDK-ARM manuals looking for a way to do something I did when using the Rowley CrossStudio tools, but I can't find what I'm looking for.
Basically, my app is too large to fit in the FLASH in my MCU (lots of graphics assets). With CrossStudio, I could set my project up so that the graphics assets were located in an external FLASH device that supported CFI (Common Flash Interface). Then when I built my app and used their JTAG tool it would write the parts of the app that belonged in the MCU to the MCU, and write the parts that belonged in the external FLASH to the external FLASH, such that my graphics assets were all available in the external FLASH device from the app code running in the MCU internal FLASH.
Is this possible with uVision/MDK-ARM, and if so, could someone please point me to where I can find the related documentation in the product manuals? Are there any KEIL app notes that describe the process? If they're there, I must be using the wrong search keywords, because I haven't been able to find them.
Thanks!
"If not, how is the IDE/JTAG tool supposed to know how to use the CFI algorithm in the loader app to actually get addresses & data onto the MCU's external address/data/control bus to talk to the FLASH chip...?"
Open the project options, and select page Utilities.
To the right of the selected JTAG interface, you have a 'Settings' button.
It pops up a dialog where you can add flash algorithms, and specifies which address ranges that requires this algorithm.
The JTAG interface doesn't know how to get addresses and data onto the MCU's external address/data/control bus.
The JTAG interface just knows how to get data into RAM, and how to get that downloaded flash algorithm to activate. The flash algorithm (that Keil supplies or that you have written yourself) knows how to pick up the data from RAM, and to drive the processor pins to write to the flash.
So in the end, the JTAG interface isn't involved in writing to your external flash. Just to hand over data to the flash algorithm.
In some situations, the flash algorithm have to play directly with processor pins or magic registers. In some situations, the flash algorithm might hand over the data to a boot loader IAP function already in existence in the processor and running code supplied by the chip vendor.
Thanks Per... your answer was very helpful.
I couldn't see how those flash loader samples could work, but now I do.
I took the CPU init code (just the I/O pin and external memory controller stuff) from my Segger JFlash script and pasted it into the init function in the (copied/edited) sample flash loader app for the NOR flash chip, and... it seems to be working perfectly now.
I am so grateful for your response... thanks again!!!