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:
 

void Timer2_ISR (void) interrupt 5
{
// ISR code
}

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:
 

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.

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:

1. Connect the USB Debug Adapter to the computer
2. 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.
3. In the settings window, scroll down and click Additional power settings.
4. In the power options window, click Change plan settings for the currently selected plan.
5. In the edit plan settings windows, click Change advanced power settings.
6. 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:

1. Connect the USB Debug Adapter to the computer
2. 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.
3. To display the list of connected Human Interface Devices (HID), tap or click the arrow next to Human Interface Devices.
4. 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)
5. Stay in the device’s property window, but navigate to the Power Management tab.
6. 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.

1. 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.
2. 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.
3. In the details pane, right-click EnhancedPowerManagementEnabled, and then click Modify.
4. Change the Value data to 0, and then tap or click OK.
5. 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.

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 

 

Questions: 

Is there a reliable way to distinguish between a power-on reset and a power supply monitor reset using the PORSF bit in the RSTSRC register of a EFM8 device?  Can the presence of a signature value written in RAM upon initial cold boot be used to detect if the last reset that caused the PORSF bit to be set was a voltage monitor reset?  Finally, can the state of power supply monitor bit (VDM0CN.VDMEN) be used to determine whether the most recent reset was a POR or power supply monitor reset?

Answer:

It is not possible to accurately distinguish between a cold POR and a VMON-induced POR on these devices.  Cold power up as well as voltage monitor reset both trigger the same flag (RSTSRC.PORSF), and all other flags are considered indeterminate when PORSF flag is set.  Additionally, the contents of any RAM location after a brown out/VMON event is indeterminate (i.e. you can not be sure that RAM contents are unchanged), eliminating the possibility of using a "signature byte" in RAM that is written immediately after initial power on (cold boot) to detect a supply monitor reset.

As for using the VDM0CN.VDMEN bit for detection of a VMON POR as opposed to a power up POR, this will not work because after any POR, the voltage monitor is enabled and selected as a reset source, so this bit will read '1' after either kind of reset.  The VDM0CN.VDMEN bit is "sticky" in the sense that after any reset other than a POR of VMON reset, the bit will retain its status, meaning that if you disable the voltage monitor as a reset source or disable the supply monitor (i.e. write '0' to VDMEN or PORSF), the voltage supply monitor will remain disabled or disabled as a reset source across all but cold POR.  If you do not ever write to the RSTSRC.PORSF, the voltage monitor will remain enabled and enabled as a reset source, as this is its default state out of any POR: "This monitor is enabled and enabled as a reset source after initial power-on to protect the device until the supply is an adequate and stable voltage." (EFM8BB3 RM, sec. 9.3.3, page 84).  Thus, any other reset besides a POR or VMON reset will not alter the enabled state of the VMON or its status as a reset source. 

To summarize, the following conditions are true:

1) On true power-up POR (cold boot) OR supply monitor POR, the voltage monitor is enabled and enabled as a wakeup source when the device comes out of reset.

2) The enable state of the supply monitor will persist through all other resets.  Thus, if you never disable it, it will always be enabled.  If you disable it as a wakeup source or disable it as a wakeup source and disable the supply monitor itself, these conditions will hold across all other resets except cold-boot POR, unless you re-enable supply monitor and/or supply monitor as reset source.

3) In the event that you disable the supply monitor as a reset source and disable the supply monitor, the following applies: "In systems where this reset would be undesirable, a delay should be introduced between enabling the supply monitor and selecting it as a reset source."

The following are two suggestions if you must have additional information about the conditions leading up to the setting of the PORSF flag:

1) Use an external power supply monitor

2) Monitor the supply voltage using the ADC and perform some action after the voltage starts to drop but before the VMON threshold is reached.  Although this will not help in determining if the last POR was cold or VMON induced, it could give an early warning prior to a brown out event if the supply voltage were to drop.

Yes.  You can send the CSP data to a UART and connect that to a host PC (for example, using one of our USB to UART interface devices).  You will need to select the com port under "dedicated serial ports" in the popup that appears when you select "Use device" in CSP.  You will need to make sure your serial settings (baud, data, stop, parity) match the settings of the UART.  Also make sure the COM port is not opened by any other program when you connect (such as a terminal program).

One point to keep in mind while using the ADC in autoscan mode being triggered by the external pin (CNVSTR) is to make sure that the Single Trigger enable is not set to 1. Setting STEN = 1 would imply that a single trigger is required to complete the whole autoscan sequence. But, the motivation for having an external conversion start is to get a sample at an exact instance of time while the idea behind having scan mode is to measure contiguous channels. Since these are mutually exclusive requirements, external convert start is not supported in single trigger mode. 

If STEN is set to 1 and the ADC is used with external convert start to autoscan channels, then the external channel will  trigger the ADC intermittently. For example - 

 

If a software/hardware redesign is not possible, one alternative that can be used in this case is to trigger a timer with the external convert and use that timer overflow to trigger the ADC in single trigger mode. 

During production, the LFOSC on EFM8 devices is calibrated to 80kHz such that we can guarantee it will oscillate at a frequency no less than the minimum (75 kHz) and no greater than the maximum (85 kHz) specification across the full temperature and supply range given in the datasheet.  This factory calibration is implemented by tuning the reset value of OSCLF - the Internal LF Oscillator Frequency Control bitfield (in the LFO0CN register).  After reset, firmware is allowed to adjust OSCLF (decreasing the value - toward 0000b - increases the LFOSC0 oscillation frequency, while increasing the value - toward 1111b - decreases the realized frequency).  Firmware may want to do this to implement finer compensation for voltage and temperature shifts than is guaranteed by our datasheet-specified limits (75/85kHz). 

However, doing so requires a known timebase against which firmware can calibrate the LFOSC by making small adjustments to OSCLF and observing the change in LFOSC oscillation frequency relative to the known timebase.  Adjusting OSCLF from the factory-calibrated reset value is therefore only useful when used in a feedback loop (where the effect of changes in OSCLF on LFOSC frequency are tracked and used to inform whether additional changes to OSCLF are necessary).  The EFM8 provides a hardware-supported technique for this task, as described in the Clocking and Oscillators section of the datasheet:

Calibrating LFOSC0

On-chip calibration of the LFOSC0 can be performed using a timer to capture the oscillator period, when running from a known timebase. When a timer is configured for L-F Oscillator capture mode, a rising edge of the low-frequency oscillator’s output will cause a capture event on the corresponding timer. As a capture event occurs, the current timer value is copied into the timer reload registers. By recording the difference between two successive timer capture values, the low-frequency oscillator’s period can be calculated. The OSCLF bits can then be adjusted to produce the desired oscillator frequency.

The calibrated reset value of OSCLF varies from device to device, and so does the "stepsize" of OSCLF LSBs.  In fact, the stepsize will likely vary on a single device from one end of the OSCLF range to the other.  In other words, there is no guarantee of what impact a change in OSCLF will have on a device's LFOSC frequency (other than the fact that increasing OSCLF slows down the oscillator, and decreasing OSCLF will speed it up).  For this reason, firmware should not change OSCLF outside of a feedback loop as described above, because doing so will introduce an unknown change in LFOSC0 frequency (which has impact to the WDT errata, discussed in "WDT_E101 - Restrictions on Watchdog Timer Refresh Interval").

 

Note: for information on the similar procedure for the Low-Frequency Oscillator on C8051Fxxx devices, see the KB article "Calibrate Internal Oscillator"

This project was designed as a proof of concept for controlling a segment LCD display through bit-banging on a low-cost, and low-pin MCU. The concept for this was introduced by this TI appnote: http://www.ti.com/lit/an/slaa654a/slaa654a.pdf

The LCD used in this project is a 4-digit, 4-mux display, PN: LCD-S401M16KR from Lumex. This LCD has 4 mux lines and 8 segment lines, for the control of up to 24 segments (7 segment digit x 4, plus colon and three dots).

The schematic and board layout files for this expansion board are provided in the attached zip file. Also included is a project for the EFM8BB1 STK that samples the voltage from the joystick and displays this voltage on the LCD.

Question: 

Are there any restrictions that impact when the Watchdog Timer (WDT) can be configured?

 

Answer:

Yes. The WDT is a low energy peripheral and has multiple timing requirements. Additionally the WDT logic requires certain sequences to safely change interval or modify the configuration.

First, The WDT should be DISABLED before changing the WDT configuration. Hence, before locking out the WDT disable feature or updating the WDT timeout interval, you must ensure the WDT has first been disabled. 

Second, synchronization delays apply when writing to the WDT register. See KB article Synchronization when writing to Watchdog Timer Control (WDTCN) on EFM8.

Third, If you intend to change the WDT interval, care must be taken to feed the WDT before disabling, as the WDT can trigger a reset when the interval is changed. This can happen even if the WDT is disabled. In order to avoid synchronization issues, the advised sequence is as follows.

void change_interval()  
{    
WDTCN = 0xA5;          // Refresh WDT    
// Insert code to wait for 2 divided LFOSC0 clock periods    
WDTCN = 0xDE;          // Disable WDT (first key)    
WDTCN = 0xAD;          // Disable WDT (second key)    
// Insert code to wait for 3 divided LFOSC0 clock periods    
WDTCN = WDT_interval   // Change the current WDT interval to a lower interval with the MSB cleared to 0    
// Insert code to wait for 1 SYSCLK clock period } 

 

Question: 

What are the synchronization implications of controlling the WDT (which runs off the low-frequency oscillator in the LFOSC0 clock domain) with writes to the WDTCN register via the MCU core (which runs in the SYSCLK domain)?

 

Answer:

A synchronization delay of slightly more than 2 LFOSC0 clock cycles (worst case) is required for the write to WDTCN from the SYSCLK domain to propagate to the WDT counter in the LFOSC0 domain.  Hence, your application should accommodate a 3 LFO clock cycle delay between writing to WDTCN and that write taking effect.

This means you should enforce a wait of 3 LFO clock cycles after issuing a WDT DISABLE command before assuming the WDT to be in the disabled state.  Similarly, plan to issue a WDT RESET (i.e. "feed", "pet", etc.) at least 3 LFO clock cycles before the actual expiration of a running WDT in order for the reset to take effect before the WDT triggers a system reset.  See KB article "Updating the Watchdog configuration on EFM8" for additional considerations when writing to WDTCN.

Note that the LFOSC0 clock is subject to the internal divider (configured by OSCLD, "Internal L-F Oscillator Divider Select", in LFO0CN).