I support an on-going project involving 5 MCUs running in parallel, which I build with uVision 3 (C51 = V8.02; BL51 = V6.00).
I am running out of code space in one of them. I currently use the SiLabs C8051F046, which has 32k of flash, and want to migrate to the C8051F044, which has identical parameters, except the flash goes all the way to 64k.
I have tested a unit after changing the DEVICE in the old project file from C8051F046 to C8051F044. and it works fine. We may replace all 5 sockets with the new part number, as the price difference is less than a dollar, and it would prevent chances to make mistakes at the contract assembly house that stuffs our boards.
I want to know if I replace the MCU for an app that is smaller than 32k, do I have to re-build all those apps that are already in production, and programmed from hex files with the new DEVICE in my project file? Some of them must support up to 24 configurations for each release.
If the answer is 'yes', why is that?
If the answer is 'no', why do I have to specify a device every time I create a new project?
Can't find any mention of this in the manuals, app notes, knowledge base or this forum.
TIA for your advice.
============================================================ Gary Lynch | To send mail, no$pam in domain name lynchg@no$pam.com | must be changed to stacoenergy. ============================================================
Keil tools don't use the "device" setting for much in the way of code generation. The device affects the simulator strongly -- how else would the sim know which peripherals should exist? -- and supplies some default parameters for memory sizes and such. You get different headers for the different variants to represent the peripherals and extra SFRs each has. Such options can be controlled from the compiler command line; the "device" setting gives you a default command line in uVision.
There are some hardware differences that affect generated or linked code: the Philips MX extensions, for example, or the existence of dual DPTRs.
Simply changing the code memory size from 0..32K to 0..64K isn't going to affect the way the code operates.
You should review the data sheets for the parts to make sure there aren't any other changes. If, for example, a later version changes the flash programming method, or moves a bit in an SFR, the old code won't work. The chip manufacturer generally has an incentive not to break their customers' old code this way for parts that are supposed to be improved versions of old ones in the same product line, but you should still conduct that review to be sure.
You'll also want to review your source to make sure no one made any assumptions that contradict the changes in the part. For example, if the old memory size was 32K, are you sure no one uses that "extra" high order bit to store infomation and expects the hardware to alias the address back into the lower 32KB?
(That's not as crazy as it sounds. Back in the days of yore, Apple Macintosh owners had trouble when upgrading from 68000-based machines to 68020-based machines. The 68K had 24 bits of address bus, despite the fact the registers were 32 bits internally. The '020 exposes all 32 bits of the data bus for a larger memory space. Turned out that some too-clever programmed used the upper byte of their pointers to store data and "save memory", which worked fine when tested on the 68K as the upper byte never made it out of the CPU package. But on the '020, that byte was visible, and could cause the pointer to point somewhere it shouldn't. Upgrade your CPU and the program stops working...)