Hi,
for the bootloader, integrated into the main project, I need to link the "__aeabi_uidivmod" to a fixed location within the bootloader section of my external flash memory.
How can I manage that? I tried these expressions in the bootloader section of the scatter loading file, but it didn't cause something:
aeabi_* (+RO) *armlib/c_* (+RO) *armlib/h_* (+RO) *armlib* (+RO) *armlib*
Any ideas?
BR Detlef Weidner
You really shouldn't.
The best way to not find later that you have shot yourself into the foot is to build the boot loader and the application as two separate projects, or as separate targets for the same project. But each produced binary should be 100% stand-alone, allowing you to make changes to one or the other without breaking anything.
If you can't afford the ROM space for completely independent binaries, then your boot loader is too complex, or you have selected a too small processor.
Thank you Per for your assistance,
I think the best way was it to link all the needed libraries twice into two separete memory regions (bl and app), if armcc supports something like that. The advantage of handling with one project is the single file output for the target and the possibility to debug both simpler in the target.
I just developed a single project solution in the past, using the gnu-arm compiler toolchain. Keil stopped the support of later versions of the gnu toolchain, so we were forced to switch to armcc. In the named older project I linked the libs and veneers to the bootloader section. Unfortunately the linker handling between both toolchains (.ld and .sct file) is very different.
Maybe you are right and it's cleaner to make two targets. But I did not understand how to manage two separate targets for the same project in µVision. Could you give me some assistance? Independently of going a better and cleaner way it would be interesting to find out how to link the libraries and helper code to a fixed location.
In my experience (and honest opinion) uVision is close to useless for managing different targets, so I'd suggest that you just keep two different project files.
I'm using separate projects for my bootloader and the application(s). This will make debugging the application slightly more cumbersome, but in my case I mostly debug via a serial port anyways. I am, however, using ulink/jtag for downloading to target (quicker than the serial port), and this is no problem, as my projects are configured to erase only the used sectors. When I download my application code to the target from within uVision, my bootloader is not affected/erased. When the target is reset, my bootloader runs first and starts the application. If I then want to debug the application from within uVision, it fails about 50% of the time (and sometimes uVision also crashes), since my bootloader obviously confuses the debugger.
@Per,
Would you say your comment applies to const data as well? For example an image to go on the LCD splash screen during boot but also used in the application.
I'm thinking of using a custom symdefs file to share const data between the 2 apps.
You could make the design choice to have your constant data (or a pointer to it) at a fixed location (such as somewhere last in the boot loader image) and then have the main application use this reference to get access to the copy.
You must do it in a way that you can rewrite your boot loader, making significant changes, and still be able to keep this access mechanism functioning.
I often use the last 16 bytes for image information. Version, crc of image etc. Such a block could contain an offset to your string. Or a pointer to a pointer table of a larger set of resources that you want your main application to access.