We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
By boot code consists of two projects. Both are written in C using small memory model. One I call fixed boot which is contained in FLASH memory. The other I call flex boot and it is downloaded from a PC to internal RAM if a software update is required. Flex boot contains FLASH erase and programming algorithms for several devices. Fixed boot calls functions in flex boot via a function table located at a fixed address. My fixed boot project reserves memory 0xC000 - 0xD7FF for flex boot. For this scheme to work correctly I beleive that I need to insure that both projects setup the following items the same way: 1. The system stack 2. The main registers 3. The users stack 4. DPP registers The first three I can handle but I am unsure how to handle the DPP registers. I posed this question to Keil support and they suggested to initialize them in the startup.a66 file. I am confused at how this would work and so far have not been successful in getting an explaination from them. The compiler uses the DPP registers to calculate addresses. If I change the contents of these registers in the startup code, won't the compiled code calculate the wrong address??? Would someone please explain this too me. Also I would appriciate any comments on things I might be missing or need to be careful of in the fixed/flex boot scheme I described. Thanks in advance, Walt
Jon is right, the DPP1 will make it so the flex functions won't be able to access it's NCONST members (looks like a 36 byte function lookup table and the entry vector). I assume the system works like this; Fixed boot running. Downloads and stores flex boot (hex file with addressing). Calls entry vector at 0xC000. Entry runs 'CInit' code (Setting DPPs to flex's settings.) Entry vectors to flex's main(). Main finishes flex's initialization and somehow returns (either the function table is fixed at 0xC010 or it's address is returned). Fixed does it's thing using the function table entries. A problem only occurs if flex accesses these constants. If not, just eliminate the DPP1 change in 'start167.a66'. If flex must access them, you can try one of the following (from simplest to most difficult); 1) Get rid of the nconst class in flex. Make all constants huge. Remove the nconst class from the L166-Locate tables (may require not using default settings). May not be allowed. Modify 'Start167.a66' so DPP1 is not changed. Check the map file for no nconsts. 2) Save, modify and restore the DPP0-2 registers at each flex call. Make certain there are no references to nconst or ndata outside the area. 3) Make a single function (pointed to by the 0xC000 vector which expects a command in R8 (1st argument) plus a void pointer to other, command dependent, data (R9). Put a small assembly function at _RESET in 'start167.a66' which stores and changes the state and then switches using the argument (eg. 0 = initialize, 1 = erase address...). This would probably get rid of all consts and protect you at the same time. These are the problems which caused me to decide assembly was easier to code and less apt to cause problems in the future. In assembly you just need DPP3 = 0x0003 for SFR addressing, everything else can be extended addressing. Best luck
Jon and Scott: Ah yes, I am now seeing the light. Thank you both for your help. I am going to try to eliminate the nconst class in flex-boot as Scott suggested. -Walt