Question:

What causes the L121 Improper Fixup error in Keil C51? How can I fix it?

Answer:

The most common cause is that, when the code was compiled, the compiler assumed functions were going to be close enough together to use the ACALL instruction, which can only jump 2k from its current destination. However, if the linker places functions farther apart than this, this fixup error occurs.

You can resolve this issue by changing the Memory Model setting in the Compiler to Large (program size 64k).

Question:

The following figure from the C8051F12x-13x datasheet describes the division of program memory into memory “banks.”  The datasheet refers to a Common code bank as well as Banks 0-4 and shows Bank 0 as always mapped to memory locations 0x0000 – 0x7FFF. 

From the figure, it appears that 2 copies of the first 32k of program memory exist in the device, and if IFBANK = 0, then the same memory contents are accessible from 0x00000-0x7FFF as well as from 0x8000-0xFFFF.  Is this correct?

Answer:

The "Common" bank and BANK0 are the same physical memory, with address mappings from 0x0000 to 0x7FFF and from 0x8000 to 0x0FFFF, respectively.  The COMMON bank is always accessible from 0x0000 to 0x7FFF, regardless of the value of IFBANK.  If IFBANK = 0, then the region from 0x8000 to 0x0FFFF will contain the same data as the region 0x0000 to 0x7FFF, though this data exists in only one physical memory bank. Banks 1, 2, and 3 are all separate physical memory locations, but are all mapped to 0x8000 to 0x0FFFF, and are accessed depending on the value of IFBANK.

The above discussion applies for instruction fetches with regard to the value of IFBANK, however an analogous discussion applies to data/constant memory accesses (MOVC and Flash MOVX instructions), and applies based on the value of COBANK.

Setting this up code banking properly in the Silicon Labs 8-bit IDE as described in AN130: Code Banking Using the Keil 8051 Tools and the AN130 Example Code should result in automatic handling of bank switching.

Question:

Is there a way that I can obtain older 8-bit SDK (8051 SDK) versions in Simplicity Studio?

Answer:

It should be possible to download and use an older SDK version in Simplicity Studio when developing code for an 8-bit C8051 or EFM8 device in Simplicity Studio.  The following steps should allow a user to obtain older SDK versions:

1) In the Simplicity Studio [Launcher] perspective, click the [Software Update] button:

2) If necessary, click on [Package Manager]:

3) In the [Package Manager] window, select “8051” from the [Categories] dropdown menu and select “All” from the [Version] dropdown menu:

4) Select the desired SDK version and click [Install].  Once installation is complete, that SDK should be available for use in example projects as well as empty C8051/EFM8 projects. 

As of this writing, it appears that 8051 SDK versions as far back as 8051 SDK – 4.0.0 are available using this method.

Question:

What does NRND really mean and what should the take away be if comparable or replacement devices have the same longevity commitment?

Answer: 

NRND typically means that we anticipate or that we've seen a decline in customer sales for a given device and thus it is unlikely that we will continue to produce this device beyond our longevity commitment.

Many of our 8-bit devices have the same longevity commitments but are in full production and do not bare the NRND label. This usually indicates that the device continues to be purchased in large quantities by our distributors/customers and as of now, the device is in continuous production to keep up with demand. This does not guarantee production beyond our longevity commitment, as we cannot predict the market through that date, but the larger customer base is a good indicator that we may continue to support this device beyond our initial commitment.

For a look at our 8-bit longevity commitment, you can visit this link https://www.silabs.com/products/mcu/8-bit/longevity-commitment.