Hello, I am working on a USB based bootloader for a LPC 2468. I want to split on chip flash between the bootloader (flash sectors 0-2), while the remaining available would be application code. My problem is that even though I read some of the documentation (linker...), I am not sure how I should address this issue: Do I make new execution regions in my scatter file? Do I use absolute code placement? If somebody could give me a small put to the right direction, that would be great...
You would normally build as two separate applications (possibly as two targets in the same project file) and just specify a different ROM address range.
Just note that you must take care to get the application interrupt vector table remapped.
thanks. just to be sure: to create a real distinction between flash space sections, is it enough to create that separation by the Target menu? hence, in the boot code target I define ROM usage from 0x0 with size 0x4000, while for the application target I can define the Flash start at 0x4000? The map files look good but I am not sure.
Almost enough. Besides defining the ROM addresses as you wrote, you must also take a look at the memory mapping of the interrupt vector table in the assembler startup file for the application. When the application is started, it must do a remapping of the interrupt vector table, so the processor will use the vectors from the application and not the vectors from the boot loader.
thanks again - I know about the need to remap of the interrupt vectors. I am almost there - can jump from the boot code to the application but I have one serious problem - the bootloader must access external RAM, but everytime I enable the EMC via the startup file, the bootloader's reset vector is not mapped to address 0x0 where it should be but rather to another address (see http://www.keil.com/forum/docs/thread13960.asp). I now know it has something to do with the EMC so something goes wrong during the build. Any suggestions?
this is an interesting failure. I have tried it myself and found out the following, that might be worth reporting to Keil as a bug in the tool chain (unless I'm missing something which is very possible)
if you have a variable, absolutely positioned in the code using something like this (RealView syntax):
const unsigned crp __attribute__((section(".ARM.__at_0x1FC"))) = CRP;
or
const unsigned crp __attribute__((at(0x1FC))) = CRP;
then, if you enable the external memory controller (EMC) via the startup file - the reset vector is no longer mapped to address 0x0 ! The solution is no use a memory mapped I/O like pointer:
unsigned *crp = (unsigned*)0x1FC ;
you can try it yourself using the NXP's AN10764 example.