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.
Hi, I am using an 80C400, I have flash located from (CE3)0x400000 - 0x4FFFFF and RAM located at (CE0) 0x010000 - 0x1FFFFF and (CE1) 0x200000 - 0x3FFFFF. I have an external crystal clocking at 18.432MHz. The problem: If code is written in C51 which resides in flash, and the 80C400 system clock is set for x4 the application will lock due to the slow speed of the flash. It is not possible to put an address latch into the design since the hardware is already built. The system RAM is battery backed, and the battery can be removed from the system at any time. My thought for a solution: Write an application which does not access FLASH at all. Then write a separate loader to reside and operate at clock x1 out of flash. Copy the application code to RAM from flash and then redirect to the application residing in RAM. Questions: How do I get the application into RAM. (VIA a custom serial loader? (Parts cannot be programmed but reside on the PCB)) Are there any examples anyone knows of that are similar to my situation? I have tried using USERCLASSes and segmets with separate C files, massaging hex files and copying code from FLASH to RAM, but so far I have not had consistent results. Thanks for any help anyone can give. Bill
This is a pretty common problem with faster processors. A lot of systems have some sort of bootloader and execute from RAM for faster speed. You seem to have the right idea. You need two completely separate programs, the boot loader and the application. The boot loader runs with the 1x clock, and copies the application into the RAM that's mapped as your program store. The app is just data to the bootloader; the two programs aren't linked together. The biggest problem is not having the boot loader step on itself while copying the application code. You might, for example, want the app to reside starting at address 0, but if that's also where the boot code lives, you'll have a problem. One answer is to write the boot code so that it copies its copy routines (at least) into the high end of RAM. Then the boot copies the app starting from the low end of RAM. If you've got bank-switching hardware of some sort, then it gets easier, since you might be able to map the app's physical addresses for data store to boot code program store, and run the boot code from there. Starting the application is just a matter of jumping to its first executable location, which should be offset 0.