Hi,
In my compeny we are develope Embedded SW on the AT89C51RD2. The SW include BL & APP that compile together (due to no enough flash space). The purpose of this SW is to be able to upgrade only the Application section by writing the flash memory (The BL section is stored from 0x0054 to 0x5000 in the flash and the app is from 0x5001 to 0xFFFF). In order to be able to do it, i seted all the function in the BL section and the constants to absolute address in the flash memory (By using ?CO?, ?PR? - linker directive) and the uninitialized global variables were seted to fixed address by using _at_ keybord. The global variables of the App (0x5000 - 0xFFFF) section are free to link by linker.
My questions are: 1. What happened with the uninitialized global variables, where are they stored ? I know the the compiler initilaized thaem to zero but is there BSS locaation ? if so where is it ? and is it posible to set it for a absolute address in the XDATA ? 2. If the first sw was compiled and burn to the device and i changed only the application section (global variable was added) and compile it again but i want burn only the application (0x5000 and above) by using __api_wr_code_page, how is the SW will know about the new address of the new global ? 3. Where is the address of the global variables were stored (not initilaized, i know that the init global variables data were save in the C_INITSEG segment and it is copy to the RAM after the STARTUP and befure the main)?
I know it is complicated (and my english is bit bad) but i realy need your help. Thanks.
All of this requires you learn a lot about your architecture, compiler and linker. I could provide you a comprehensive analysis based on my experience, but I would charge you for my time.
The 8051 is archaic, are you sure there aren't more cost effective solutions in 2014? There are ARM Cortex-M0 parts running $0.30
The ARM RealView linkers would take a definition file describing the address of functions in a ROM image, these addresses could be harvested from a .MAP file. I'm sure a similar method would exist in other linkers, or could be contrived from a suitably crafted object file.
You might want to start by analyzing the foot prints of the code you have now, what code is consume what amount of space, and what has shared commonality between the Boot Loader and Application if you split them.
What size memory do you have now? How much do the combined, and split, versions take? Identify the library functions that consume the most space.
The static space is typically initialized from a list of things to zero, and things to copy. Even if you partition where these allocations live, the list will still be difficult to separate.
You need to think in terms of what is easy and logical for the linker to generate, and apply those ideas to your problem, rather than come at it the other way and bludgeon the tools into the way you think you want to solve/address the problem.
Other than that, make the Boot Loader VERY simple, with enough suitably tailored and optimized code to perform the update function.