This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F47187: WHat is the benefit of mirrored RAM area?

Other Parts Discussed in Thread: MSP430F47187

Hi,

 

 MSP430F47187 has a RAM 2KByte area mapped between 0x200-0x9FF. This area is the mirror of actual ram area that is from 0x1100 to 0x18FF. What is the benefit of this mirror?

 

Thanks.

 

  • Inside an MSP family, there are different devices which are mostly identical. Some of them have more RAM, others more FLASH.

    The mirrored RAM area allows code that was compiled for one of them to be directly used on the other, as long as the code fits into the flash.

    One example is the MSp4301x family. The 168, 169 and 1611 are very similar. The 169 has more flash (and less ram, located below the BSL area) and the 1611 has less flash but more ram, which is located above the BSL area, since below it there isn't enough space. Yet it mirrors part of its ram to the area below. The 168, has less flash and less ram. So if you compile a program for the 168, it will run on the 169 (which has just more flash) but also on the 1611, which has the same amount of flash as the 168, but its bigger ram is somewhere else. Because of the mirroring, the 168 program will still run as it finds the ram (the small portion it needs) at the same place as it expects it. And the area between these two RAM locations is kept identical for all devices.

    I don't know for the 47187 and the other derivates, but I guess things are similar: one small portion of the ram where it is on the other devices, and hten the whole bunch again at a different location where it won't fit on the others.

  • As I understand we can say no benefit for C users. Right?

     

    10x.

     

  • Indeed, no direct benefit for the plain C side (or assembly side). I don't know any fancy programming trick that would make use of it. Other than writing firmware for one device and let the binary run on the 'bigger' one without need of different projects for each target (assuming that the used hardware is attached identically).

    Except perhaps having shadow variables in one mirror and another set in the other mirror, so they look different while they are identical. This could effectively confuse anyone who wants to disassemble and analyze your code  :)