Question: What is the Linker Control File and how to use it in Simplicity Studio?
Answer: The linker control file is a type of command or response file that contains only the linker directives. All other .OBJ files and .LIB files are not included in this file. The linker file (.lnp format) generated by Simplicity Studio when compiling an 8 bit project contains both the object/library files and the linker directives. The last line in the linker file is the script that is used in the linker control file. Do note that Simplicity Studio auto generates the "To CUSTOM_PROJ" line, therefore this line is excluded from the linker control file.
An example of a linker control file script and its relevant project is attached in this article
To use the linker control file:
1. Import the project into Simplicity Studio by going to [File] -> [Import]
2. In the [Project Explorer] window, right click on the project and go to [Properties]
3. Navigate to [C/C++ Build] -> [Settings] -> [Keil 8051 Linker] -> [General]
4. Select [Use linker control file] and browse to the linker control file
5. Click [Apply] -> [OK]
6. Build the project
To ensure the reliability of a device that is drawing power, there is a maximum safe junction temperature (Tj) that should not be exceeded during the lifespan of the part.
The standard for this maximum temperature is around 150 C, and devices expected to source/sink large amounts of current, or operate in high temperature environments need to have this maximum temperature considered.
The ability for a device to dissipate heat is characterized by its thermal resistance to difference interfaces. These interfaces are the ambient air (Rth ja), the PCB (Rth jb) and the package or case (Rth jc). These values are measured in degrees celsius per watt (C/W). These values can help understand the limits of safe operation for a device for given conditions.
Our C8051F50x devices do not include this value in the datasheet, but we have characterized these values for the typical case. These are listed below. Note that these values are not guaranteed maximums, and only estimate the values across devices.
Conditions: Ambient temp=85 C, Die dissipation power = 1W
The header file compiler_defs.h and the definitions it provides are deprecated, and have been removed from the latest SDK of the Silicon Lab IDE (5.50). The header has been replaced by si_toolchain.h. All of the example code provided with the Silicon Labs IDE now uses si_toolchain.h and its definitions.
The main difference between the two headers is the name of some of the defines. For example, SI_SBIT replaces SBIT, uint16_t replaces U16, and SI_INTERRUPT replaces INTERRUPT.
In order to migrate a project from one header to another:
Remove _compiler_defs.h from the project and add si_toolchain
Replace "#include <compiler_defs.h>" with "#include <si_toolchain.h>
Change defines used in file. Search and replace is useful for this
For more information on why this change was made, see this KB article: https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2017/03/31/software_licensinga-qzLc
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).
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.
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.
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.
Why do I receive syntax errors in Simplicity Studio when defining an interrupt? The code compiles and works correctly, but declaring an interrupt, such as this one, gives a syntax error in Studio:
This occurs since Simplicity Studio uses a generic C syntax parser when looking for syntax errors in code. It doesn't understand compiler-specific C code, like that used by Keil C51 to define an interrupt function - the 'interrupt' keyword and interrupt number after the function declaration aren't standard C, so it throws a syntax error. Keil, however, when the project is compiled, understands this syntax and compiles the code correctly.
We have a work-around for this visual error by the way of macros in si_toolchain.h. If you use the SI_INTERRUPT(name, vector) macro, it will generate different declarations based on which tool is viewing the code. If __SLS_IDE__ is defined (that is, if the Simplicity Studio parser is looking at the code, it omits the interrupt vector number from the actual declaration. If Keil C51 is viewing the code, it places the vector number in the correct location for Keil to compile it correctly.
For example, if we used the following:
SI_INTERRUPT(INT1_ISR, 2)
In the IDE, this would generate:
void INT1_ISR (void)
But, for C51, this would generate:
void INT1_ISR (void) interrupt 2
This would eliminate the syntax error, but still allow Keil to compile the interrupt correctly.
I’m running Windows 10/Simplicity Studio 4 and I am trying to power my Silicon Labs device through the USB Debug Adapter (UDA), but the UDA keeps shutting off after I flash the device. What gives?
Answer:
The UDA configurator in Simplicity Studio 4 has the option of allowing the UDA to continue to provide power to the target device, even after disconnecting from a debug session. This is a setting in the UDA that attempts to maintain USB power through the USB host.
However, Windows has several additional USB “features” that will try to save power by shutting down what the OS deems as unnecessary USB devices. The first component, which is more user configurable, is called USB Selective Suspend. USB Selective Suspend allows the hub driver to suspend an individual port without affecting the operation of the other ports on the hub. There are many ways of disabling this feature, but for the scope of this article, we’ll stick with the user-friendly methodology.
On a global scale, you can disable USB Selective Suspend on all USB hubs/devices. Here’s how to do this in Windows 10:
Connect the USB Debug Adapter to the computer
Open the Power & Sleep settings window. To do this, type Power & Sleep in the Windows toolbar search bar, and then tap or click Power & Sleep in the search results.
In the settings window, scroll down and click Additional power settings.
In the power options window, click Change plan settings for the currently selected plan.
In the edit plan settings windows, click Change advanced power settings.
In the next power options window, open the tree labeled USB settings/USB selective suspend setting and change the settings to disabled.
To disable USB Selective Suspend on individual USB devices:
Connect the USB Debug Adapter to the computer
Open the Device Manager. To do this, type Device Manager in the Windows toolbar search bar, and then tap or click Device Manager in the search results.
To display the list of connected Human Interface Devices (HID), tap or click the arrow next to Human Interface Devices.
Find the USB Input Device associated with the UDA. To do this, right-click each item labeled USB Input Device and open up the device properties window. From here, select the Details tab and select Device instance path from the property drop-down list. Locate the device with the device instance path that includes VID_10C4 and either PID_8044 or PID_8045. This is the UDA. While here, make a note of the Instance ID, which is the unique identifier at the end of the device instance path (e.g. USB\VID_10C4&PID_8045\UDA000C5691)
Stay in the device’s property window, but navigate to the Power Management tab.
Uncheck the checkbox next to Allow the computer to turn off this device to save power.
For external ports (externally powered hubs), either of the previously described methods will enable the UDA to continue powering the target device even after disconnecting. However, for built in ports, there is an additional power management “improvement” introduced in Windows 8.1 and beyond which will suspend a USB Human Interface Device (HID) if there is not an application actively accessing it! To disable this feature, a value in the system registry needs to be changed.
Start Registry Editor. To do this, type regedit.exe in the Windows toolbar search bar, and then tap or click regedit in the search results.
In the navigation pane, find the registry key that corresponds to the problem device. To do this, follow these steps:
Tap or click the arrow next to the HKEY_LOCAL_MACHINE folder to expand it.
Expand SYSTEM.
Expand CurrentControlSet.
Expand Enum.
Expand USB.
Locate the folder whose name contains the VID and PID that you noted in step 6 (for example, locate VID_10C4&PID_8044 or VID10C4&PID_8045), and then expand that folder.
Expand the folder that matches the Instance ID from step 4 in the individual suspend disable walk-through above.
Tap or click Device Parameters.
In the details pane, right-click EnhancedPowerManagementEnabled, and then click Modify.
Change the Value data to 0, and then tap or click OK.
Exit Registry Editor.
The USB Debug Adapter will now stay powered, even after disconnecting from a debug session.
If for some reason you need to re-enable the Enhanced Power Management setting follow the same steps in the section above except that, in step 4, change the Value data back to 1.
Are there any software flashing tools for EFM8/C8051 devices available for Linux (such as the like the flash programming utility for EFM8/C8051Fxx devices)? Are there any C2 or USB Debug Adapter (UDA) Linux driver available?
Additionally, I have attached several files to this article that I hope will help enable programming of the EFM8/C8051 devices from the Linux command line. One is a library file that you can utilize with your own wrapper functions to program the device. This is the file "libslab8051.so." The other is a header file that describes the functions contained therein that should enable you to program the C8051 using the USB Debug Adapter that you already have. This file is "SLAB8051.h." I have also attached the header file "SLAB8051Errors.h" to this article.
Unfortunately, we do not really have additional documentation or examples of the use of "libslab8051.so." The DLL that this was based on, however, is called SiUtil.DLL and while we do not have a linux version of this DLL, we do have an application note (AN117) that may have information that translates over to the functions of "libslab8051.so" and could be helpful to you. You can find this application note here: https://www.silabs.com/Support%20Documents/TechnicalDocs/an117.pdf
8-bit Knowledge Base
Linker Control File in Simplicity Studio
Question: What is the Linker Control File and how to use it in Simplicity Studio?
Answer: The linker control file is a type of command or response file that contains only the linker directives. All other .OBJ files and .LIB files are not included in this file. The linker file (.lnp format) generated by Simplicity Studio when compiling an 8 bit project contains both the object/library files and the linker directives. The last line in the linker file is the script that is used in the linker control file. Do note that Simplicity Studio auto generates the "To CUSTOM_PROJ" line, therefore this line is excluded from the linker control file.
An example of a linker control file script and its relevant project is attached in this article
To use the linker control file:
1. Import the project into Simplicity Studio by going to [File] -> [Import]
2. In the [Project Explorer] window, right click on the project and go to [Properties]
3. Navigate to [C/C++ Build] -> [Settings] -> [Keil 8051 Linker] -> [General]
4. Select [Use linker control file] and browse to the linker control file
5. Click [Apply] -> [OK]
6. Build the project
C8051F50x junction temperature and thermal resistances
To ensure the reliability of a device that is drawing power, there is a maximum safe junction temperature (Tj) that should not be exceeded during the lifespan of the part.
The standard for this maximum temperature is around 150 C, and devices expected to source/sink large amounts of current, or operate in high temperature environments need to have this maximum temperature considered.
The ability for a device to dissipate heat is characterized by its thermal resistance to difference interfaces. These interfaces are the ambient air (Rth ja), the PCB (Rth jb) and the package or case (Rth jc). These values are measured in degrees celsius per watt (C/W). These values can help understand the limits of safe operation for a device for given conditions.
Our C8051F50x devices do not include this value in the datasheet, but we have characterized these values for the typical case. These are listed below. Note that these values are not guaranteed maximums, and only estimate the values across devices.
Header file compiler_defs.h deprecated in Silicon Labs IDE 5.50
The header file compiler_defs.h and the definitions it provides are deprecated, and have been removed from the latest SDK of the Silicon Lab IDE (5.50). The header has been replaced by si_toolchain.h. All of the example code provided with the Silicon Labs IDE now uses si_toolchain.h and its definitions.
The main difference between the two headers is the name of some of the defines. For example, SI_SBIT replaces SBIT, uint16_t replaces U16, and SI_INTERRUPT replaces INTERRUPT.
In order to migrate a project from one header to another:
For more information on why this change was made, see this KB article: https://www.silabs.com/community/mcu/8-bit/knowledge-base.entry.html/2017/03/31/software_licensinga-qzLc
Error L121: Improper Fixup
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).
Code Bank Mapping (or Understanding Mapping of Common vs. Code Bank 0-3)
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.
Obtaining Previous 8051 SDK Versions in Simplicity Studio
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.
What does Silicon Labs mean by Not Recommended for New Design (NRND)?
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.
Syntax error in Simplicity Studio when declaring interrupts?
Question:
Why do I receive syntax errors in Simplicity Studio when defining an interrupt? The code compiles and works correctly, but declaring an interrupt, such as this one, gives a syntax error in Studio:
Answer:
This occurs since Simplicity Studio uses a generic C syntax parser when looking for syntax errors in code. It doesn't understand compiler-specific C code, like that used by Keil C51 to define an interrupt function - the 'interrupt' keyword and interrupt number after the function declaration aren't standard C, so it throws a syntax error. Keil, however, when the project is compiled, understands this syntax and compiles the code correctly.
We have a work-around for this visual error by the way of macros in si_toolchain.h. If you use the SI_INTERRUPT(name, vector) macro, it will generate different declarations based on which tool is viewing the code. If __SLS_IDE__ is defined (that is, if the Simplicity Studio parser is looking at the code, it omits the interrupt vector number from the actual declaration. If Keil C51 is viewing the code, it places the vector number in the correct location for Keil to compile it correctly.
For example, if we used the following:
In the IDE, this would generate:
But, for C51, this would generate:
This would eliminate the syntax error, but still allow Keil to compile the interrupt correctly.
Powering Target Boards with a USB Debug Adapter does not work with Windows 10
Question:
I’m running Windows 10/Simplicity Studio 4 and I am trying to power my Silicon Labs device through the USB Debug Adapter (UDA), but the UDA keeps shutting off after I flash the device. What gives?
Answer:
The UDA configurator in Simplicity Studio 4 has the option of allowing the UDA to continue to provide power to the target device, even after disconnecting from a debug session. This is a setting in the UDA that attempts to maintain USB power through the USB host.
However, Windows has several additional USB “features” that will try to save power by shutting down what the OS deems as unnecessary USB devices. The first component, which is more user configurable, is called USB Selective Suspend. USB Selective Suspend allows the hub driver to suspend an individual port without affecting the operation of the other ports on the hub. There are many ways of disabling this feature, but for the scope of this article, we’ll stick with the user-friendly methodology.
On a global scale, you can disable USB Selective Suspend on all USB hubs/devices. Here’s how to do this in Windows 10:
To disable USB Selective Suspend on individual USB devices:
For external ports (externally powered hubs), either of the previously described methods will enable the UDA to continue powering the target device even after disconnecting. However, for built in ports, there is an additional power management “improvement” introduced in Windows 8.1 and beyond which will suspend a USB Human Interface Device (HID) if there is not an application actively accessing it! To disable this feature, a value in the system registry needs to be changed.
The USB Debug Adapter will now stay powered, even after disconnecting from a debug session.
If for some reason you need to re-enable the Enhanced Power Management setting follow the same steps in the section above except that, in step 4, change the Value data back to 1.
Linux flash programming utilities for EFM8/C8051Fxxx
Question:
Are there any software flashing tools for EFM8/C8051 devices available for Linux (such as the like the flash programming utility for EFM8/C8051Fxx devices)? Are there any C2 or USB Debug Adapter (UDA) Linux driver available?
Answer:
The following are links to two discussion threads in the Silicon Labs Community which may be of use in this matter:
http://community.silabs.com/t5/Simplicity-Studio-and-Software/Flashing-Running-from-command-line/m-p/142582/highlight/true#M10052
http://community.silabs.com/t5/8-bit-MCU/Announcing-linux-C2-flash-tool/m-p/134037/highlight/true#M41338
Additionally, I have attached several files to this article that I hope will help enable programming of the EFM8/C8051 devices from the Linux command line. One is a library file that you can utilize with your own wrapper functions to program the device. This is the file "libslab8051.so." The other is a header file that describes the functions contained therein that should enable you to program the C8051 using the USB Debug Adapter that you already have. This file is "SLAB8051.h." I have also attached the header file "SLAB8051Errors.h" to this article.
Unfortunately, we do not really have additional documentation or examples of the use of "libslab8051.so." The DLL that this was based on, however, is called SiUtil.DLL and while we do not have a linux version of this DLL, we do have an application note (AN117) that may have information that translates over to the functions of "libslab8051.so" and could be helpful to you. You can find this application note here:
https://www.silabs.com/Support%20Documents/TechnicalDocs/an117.pdf