Hi,
Currently im developing a project which takes advantage of the In Application Programming feature on the ARM7 MCU. These individual projects are a Bootloader (IAP enabled) and a Main Application.
Ive found that both Apps utilise the same drivers etc but have not seen a way in which Bootloader and Main Application firmware can reference the same drivers. In doing so I can save vast amounts of code space etc. Im not sure where to start, ive seen older examples from uvision2, 8051 but nothing relevant for this MCU/Keil's Uvision4 IDE. Any ideas / keywords will be appreciated as currently ive not seen anything useful to use with the ARM7 MCU yet.
Thanking you in advance
DSP
..Tamir's solution seems viable, ill start looking into this asap. Cheers everyone.
I did some quick searching and reading on Mike's suggestion about StellarisWare library in ROM. LM3S9B96 ROM USER'S GUIDE www.ti.com/.../spmu127c.pdf
1 Introduction The LM3S9B96 ROM contains the Stellaris® Peripheral Driver Library and the Stellaris Boot Loader. The peripheral driver library can be utilized by applications to reduce their flash footprint, allowing the flash to be used for other purposes (such as additional features in the application). The boot loader is used as an initial program loader (when the flash is empty) as well as an application initiated firmware upgrade mechanism (by calling back to the boot loader). There is a table at the beginning of the ROM that points to the entry points for the APIs that are provided in the ROM. Accessing the API through these tables provides scalability; while the API locations may change in future versions of the ROM, the API tables will not. The tables are split into two levels; the main table contains one pointer per peripheral which points to a secondary table that contains one pointer per API that is associated with that peripheral. The main table is located at 0x0100.0010, right after the Cortex-M3 vector table in the ROM. The following table shows a small portion of the API tables in a graphical form that helps to illustrate the arrangement of the tables:
Would the Backward Compatibility be an issue?
...this is the route I was previously investigating which John mentions above.
ARM LTD support have replied and advised looking into creating/reading 'SYMDEF' which ive now tried through the uVision4 IDE and it does work although it has the following warnings ".\Hex\HEXOUTPUT.axf: Warning: L6307W: .text(APP.o) contains branch to unaligned destination."
As ive understood the SYMDEF generates a table listing all function / data variables addresses residing at the Bootloader App Level. Its this table ive imported into the Main App deleting unwanted references and compiled the Main App project.
Cheers all for your suggestions.
Have a good day :)
The BIOS-style method of having library functions stored in the boot loader and accessing it through a jump table or an interrupt vector can save code space.
But there is one big issue. When the library functions are generated using C/C++, there might be use of helper functions that can potentially interfere. The library code in the boot loader will get one copy of these helper functions and the application a second copy. Normally not a problem, unless these helper functions assumes the existence of RAM variables for storing some state information.
Having two sets of the helper functions means that there will be two (probably different) assumptions about where these variables are stored.