Profile

PhillipB

Profile Data

Screen Name: PhillipB

Screen Name*

Title

First Name

Address:

Last Name

URL (i.e. Company, Github, LinkedIn)

Email

LinkedIn account

Company

Phone number

Country

Bio

Indicates required field*

My Activities
Following

Member	Action	Date
PhillipB	Updated Connect Tutorial 2 - Communication Basics: Send and Receive on Knowledge Base This is the second tutorial in a series that demonstrates "the essentials" of building applications based on Silicon Labs Connect. See Connect Tutorial Series: Table of Contents for an overview of topics addressed in the series, general pre-requisites to ensure you get the most out of the exercises, and definitive Connect references for when you're ready to dive deeper. The first tutorial (Getting Started with Application Development) introduced the Connect application development construct, based on plugins, callbacks, and events. In this second tutorial, we expand on this Connect-based application concept to demonstrate basic wireless communication by implementing simple message transmit and receive operations. To conduct the following exercise, you'll need two Wireless Starter Kit (WSTK) boards, each equipped with a (preferably identical) radio board. Basic Application Example: Transmit / Receive First, create a new "Empty" Flex SDK Project as described in tutorial 1 "Getting Started with Application Development". (Just create a new project for this tutorial 2 and give it an appropriate name - you don't need to actually repeat the tutorial 1 exercise.) Radio Configuration Radio configuration is a crucial part of successful communication between devices. Importantly, radio settings in the application must be in agreement with those in the hardware. Configuring the EFR32 radio is not the focus of this tutorial (for more information on this subject, see AN971: EFR32 Radio Configurator Guide). For the purposes of this tutorial series, please take "on faith" the following steps and select a predefined radio configuration in AppBuilder/Radio Configurator to provide radio functionality in the exercises: Open the radio configurator (open the project .isc file, and select the [Radio Configuration] tab in AppBuilder), then click on Protocol Configuration. Select Connect Profile from the available radio profiles. In the radio PHY drop down menu there are several predefined PHY settings that support the radio boards available in the Silicon Labs EFR32 portfolio. Select one of these that corresponds to your target hardware (especially the radio band). By selecting a Connect profile, you ensure that a Connect-compatible packet format will be applied during transmit and receive operations. If none of the predefined radio PHYs match your target hardware, select Custom settings from the radio PHY list and then apply any necessary adjustments to settings in the radio configuration fields. If the delta between a built-in PHY option and your hardware is small enough (like a minor change in frequency, bitrate, or deviation), select that closest predefined setting first, then switch to Custom setting and make your adjustments. However, be aware that radio configuration is a complex task, and even minimal changes can result in a non-functional radio PHY. Select Plugins & Callbacks, Configure Buttons, and Generate Project Files The default plugin configuration for the Connect (SoC): Empty Example provides all the features we'll use below, so we don't need to additionally enable or disable any plugins. We will, however, need to activate some related callbacks (using AppBuilder / Callbacks, as described in "Getting Started with Application Development"), so that our application is notified when the corresponding events occur: `emberAfIncomingMessageCallback` `emberAfMessageSentCallback` `emberAfStackStatusCallback` (for future use - does nothing in the current project) Pushbutton configuration is managed using the Hardware Configurator in Simplicity Studio. As with the plugins, the default settings are suitable for our example, so we won't cover this tool in this tutorial. The buttons are initialized from the example Connect application's `main()` function. You can now generate the project (by clicking the [Generate] button) in AppBuilder. Doing so will populate the Simplicity Studio project workspace with source files and linked resources to support the configuration specified in your AppBuilder (.isc) file. We'll write our application using some these files in the following sections - for example, when we implement the callbacks enabled above. Address (Node ID) Selection The two devices which will send/receive messages to/from each other must have unique node IDs on the network. So that we can run the same firmware on both devices, we'll use button PB0 on the WSTK to select the node ID for each device at startup. When the application begins, we will first retrieve the state of PB0, then set the local (self) and remote (the other device on the network that we'll communicate with) addresses corresponding to the button state. We check the button state (and determine the correct assignment of device addresses) in `emberAfMainInitCallback()`: `if(halButtonPinState(BUTTON0) == BUTTON_PRESSED) { nodeIdLocal = 0x0001; nodeIdRemote = 0x0000; halSetLed(0); } else { nodeIdLocal = 0x0000; nodeIdRemote = 0x0001; halClearLed(0); }` You can see here that we've also used LED0 to visibly indicate the address, which helps to distinguish the WSTK boards from each other. Note that this indication is only applicable at this point (shortly after power-on/reset), as LED0 is repurposed for a different use during the later message transmit and receive operations. (If you're not sure where to find `emberAfMainInitCallback()`, review the steps in tutorial 1 "Getting Started with Application Development" to enable callbacks within AppBuilder.) Assigning Local Node ID Note: A single Connect network consists of multiple devices using a single one of the three available Connect Modes. For this tutorial (and the next few in this series), we've chosen a Direct mode Connect application for our demonstrations, as it provides both a sufficiently general platform and the fastest ramp to competency for new Connect developers. The modes are not interoperable, and the APIs vary (often significantly) among them - which makes porting from one to another impractical - so determining the optimal mode for your application is a critical first step. Other Connect Modes will be explored in later tutorials in this series, but with the API call that follows we effectively designate this as a Direct mode device. Later in `emberAfMainInitCallback()`, we join the network using the appropriate address by commissioning: `emberJoinCommissioned(EMBER_DIRECT_DEVICE, nodeIdLocal, &parameters);` At this point the network parameters are set, and the device can communicate with other devices. Button Event Handling For this exercise, we want to send a message when button PB1 is pressed. Although we could periodically check (i.e. "poll") the button state, we will instead use an interrupt-based approach available with HAL support. The function `halButtonIsr()` will be called on the "press" or "release" of any configured button. It is a weak function that is empty by default, and the application must implement it to use it. The following snippet shows one possible implementation: `void halButtonIsr(uint8_t button, uint8_t state) { if(button == BUTTON1 && state == BUTTON_PRESSED) { emberEventControlSetActive(buttonEvent); } }` Although it is possible to send a message directly from this ISR, blocking execution by conducting lengthy operations from ISR context is not recommended. Instead, we'll only activate a Connect event (to be acted upon later) and quickly exit the ISR. To create a Connect event (as described in "Getting Started with Application Development"), we add it to AppBuilder / Other / Event Configuration and implement it in `flex-callbacks.c`: `void buttonHandler(void){ emberEventControlSetInactive(buttonEvent); EmberStatus status = emberMessageSend(nodeIdRemote, ENDPOINT, 0, sizeof(messageBuffer) messageBuffer, EMBER_OPTIONS_NONE); }` Here, we've named the event "command" as `buttonEvent`, and the event "callback" as `buttonHandler`. Remember to generate the project in AppBuilder again, after you've modified the .isc file by adding this event. Since we want to call the handler only once on each button press (as opposed to the blink event we created in the first tutorial, where the event was rescheduled repeatedly), the event must be inactivated in the handler. We send a message from this handler using the `emberMessageSend()` function, where the argument `nodeIdRemote` specifies the node ID of the device to which we are addressing the message. The `endpoint` is a freely chosen value (the concept is similar to a port number in TCP/IP) which can be used to filter incoming messages. Implementing Callbacks Previously, we enabled in the AppBuilder / Callbacks tab some callbacks we intend to use in our application. We'll now implement them using the stubs that were created in `flex-callbacks.c` during project generation. The Connect stack informs the application that a message has been sent using the following callback: `void emberAfMessageSentCallback(EmberStatus status, EmberOutgoingMessage message){ halToggleLed(0); }` In the implementation above, we only toggle the state of LED0. Note, however, that this callback will fire even if the message did not actually send or the remote device did not successfully receive the message. The variable `status` will indicate this result. Handling incoming messages is accomplished through a callback as well: `void emberAfIncomingMessageCallback(EmberIncomingMessage message) { if(message->endpoint == ENDPOINT && !memcmp(message->payload, messageBuffer, sizeof(messageBuffer))){ halToggleLed(1); } }` The above callback fires when an incoming message is available. It checks whether the endpoint matches and compares the received message payload with the one we previously loaded to `messageBuffer` (this example sends the same message in both directions). There are several message properties stored in the `message` structure which is of type `EmberIncomingMessage`. See the Connect API Documentation documentation for details. Usage and Testing Compile and download the firmware onto both devices. Start (reset) one of them without pressing PB0 (it will assume node ID 0x0000 and LED0 will be off) and do the same on the other board but hold PB0 down during start/reset (its node ID will become 0x0001 and LED0 will be on). After completing the above steps, press PB1 on one of the boards. LED0 should toggle on that board and LED1 should change its state on the other board if the message is successfully received. The same sequence (press PB1 to transmit a message) should work in the other direction as well. Notes Keep in mind that it is always a good policy to handle errors/return values/statuses, and the Connect API provides this feedback in most cases. Hence, as a "best practice" we highly recommend implementing such evaluation routines. This tutorial example omitted these important features to keep it simple, easy to understand, and focused on fundamental topics. Conclusion Connect-based applications benefit from simple APIs that support radio transmit and receive operations. The Wireless Starter Kit (WSTK) platform facilitates application development for the EFR32 product families. Later tutorials in this series dive deeper into more sophisticated radio support APIs and flexible bring-up/debug/management interfaces available to Connect-based applications. API References Functions `emberAfIncomingMessageCallback()` `emberAfMessageSentCallback()` `emberAfStackStatusCallback()` `emberAfMainInitCallback()` `emberMessageSend` `emberJoinCommissioned()` `emberEventControlSetActive()` `halButtonIsr()` `halButtonPinState()` `halClearLed()` `halSetLed()` `halToggleLed()` Type definitions `EmberStatus` `EmberOutgoingMessage` `EmberIncomingMessage` Defines `EMBER_DIRECT_DEVICE` `EMBER_OPTIONS_NONE` `BUTTON_PRESSED` Show more	Oct 07 2019, 7:03 PM
PhillipB	Updated RAIL tutorial: Introduction to Multi-PHY and Multiprotocol on Knowledge Base This tutorial builds on the following tutorials: RAIL Tutorial 1: Introduction and init RAIL Tutorial 2: Transmitting a Packet RAIL Tutorial 3: Event Handling RAIL Tutorial 4: Combining Transmit and Receive To get the most out of this tutorial, some familiarity with the radio configurator is required, and it's also recommended that you understand the basics of radio protocol stacks (i.e. the OSI model). You can find these prerequisite tutorials on the table of contents site. Introduction With a customizable radio, the Wireless Gecko is a great option to support any radio configuration you need. You can set it up for standard IEEE 802.15.4, Bluetooth Low Energy, WMBus, or even the protocol (designed 30 years ago) used by your garage door opener. However, what if you need more than one of those standards? With single protocol radios, this requires a distinct 15.4 radio chip, a Bluetooth chip, and so on for each supported standard. Alternatively, with a single Wireless Gecko, you can store multiple "setups" in your device and switch between them. The only limitation is that it's still a single radio - you can't use multiple "setups" on the radio at the same time. The best way to manage the sharing of this single radio resource depends on the particular usecase targeted by your application. We provide different solutions (discussed below) to help you identify an optimal approach for your design. Channel-based Multi-PHY The most common usecase in proprietary wireless is the need to support different PHY configurations. For example: You always handle received packets the same way, but you have to receive at multiple bitrates You have an asymmetric protocol, i.e. the Rx configuration is not the same as the Tx configuration You need wider bandwidth for CSMA/CA than your normal Rx mode to pass regulatory standards You have to handle different packet formats, but not at the same time: the upper layers of the stack decide which one to use Although the PHYs are technically the same, there is a power limitation on a given channel to pass regulatory standards The PHYs are technically the same, but the channel map is uneven - it's not possible to configure it using channel spacing In these cases, Channel-based Multi-PHY is the best solution. It's called Channel-based, because in RAIL, you only need to change the channel to change the PHY. You can find a setup guide for some of these usecases in the Multi-PHY usecases and examples tutorial. Protocol-based Multi-PHY This is not as widely used as Channel-based Multi-PHY, but it's the next logical step. The typical usecases: Your device will support multiple regions, and you choose one during configuration, but the device will rarely switch between those. Your device will support multiple protocols, but the device will rarely switch between those. For this, we recommend Protocol-based Multi-PHY. In this case, you can switch between protocols by calling `RAIL_ConfigChannels()`, which will load the whole configuration. Protocol based Multi-PHY is also useful if you want to test multiple configuration setups using RAILTest: You can change between protocols using the `setConfigIndex` RAILTest command. You can find a setup guide for some of these usecases in the Multi-PHY usecases and examples tutorial. Channel-based vs Protocol-based Multi-PHY In general, you should consider your application requirements: If you want to have (for example) 20 channels, but those 20 channels are defined differently in some application configurations (typically by region), you should use Protocol-based Multi-PHY. A protocol change will be slower than a channel change, but the application doesn't even need to know which protocol is in use, since it still sees the same 20 channels through RAIL. Otherwise, in almost all cases, Channel-based Multi-PHY is a better choice. Dynamic Multiprotocol (DMP) between RAIL-based protocols If you have full protocol stacks that are completely independent, it makes sense to develop the PHY and Link layer independently as well. These layers communicate with RAIL, and the cleanest solution to this problem is Dynamic Multiprotocol. Typical usecase: One protocol is used to communicate with key fobs, while another is used to communicate in a home automation network In Dynamic Multiprotocol, the RAIL scheduler decides which protocol is active. However, it might be worth using Dynamic Multiprotocol even if you don't need the RAIL scheduler, just for the code clarity it provides by the separation of stacks. Dynamic Multiprotocol is more capable than Multi-PHY, but also more complex, so it has some drawbacks when compared to Multi-PHY: Protocol change takes 450us on EFR32xG1x. This is a fixed worst-case delay, because the RAIL scheduler must plan time-sharing of the radio resource using calculations on a known sufficient time span in order to accomodate protocol switches. It requires the multiprotocol version of the RAIL library, which has a bigger memory footprint (both RAM and code) than the single protocol version. Writing RAIL application in DMP will be the subject of this tutorial. Dynamic Multiprotocol between RAIL-based and other Silicon Labs stack protocols The usecase for this is straight forward: If you need Bluetooth and a RAIL-based protocol in the same application At the moment, Silicon Labs only provides such a DMP solution based on the Bluetooth stack and RAIL. You can access it by installing the Bluetooth SDK and starting one of the DMP applications. See AN1134 for more details, and an upcoming tutorial detailing DMP usage from a RAIL perspective. Other multiprotocol solutions You can find other types of multiprotocol mentioned in some Silicon Labs documents, but they are rarely used: Programmable multiprotocol means multiple firmware images for each protocol, and the protocol is decided during the manufacturing process, i.e. a device is either programmed to be a Bluetooth or a Zigbee device. Switched multiprotocol means two firmware images, one for each protocol. A bootloader loads the firmware needed for the protocol, and the two firmware can communicate with each other in a shared NVM storage. Protocol switching in switched multiprotocol is rather slow, and using DMP is almost always a better choice. Concurrent multiprotocol means that the PHY and maybe the lower layers of the stacks are the same, but the upper layers are different. E.g. You can run two proprietary 15.4 protocol on the same channel at the same time, but you don't really need multiprotocol specific APIs to support it. Related documentation AN971: EFR32 Radio Configurator Guide UG103.16: Multiprotocol fundamentals Show more	Jul 02 2019, 7:50 PM
PhillipB	Replied to Enabling Idle-Sleep plugin for Sink Hi Arun, You may also consult "UG235.07: Energy Saving with Silicon Labs Connect" and "AN902: Building Low Power Networks with the Silicon Labs Connect Stack" for additional guidance. Show more	Jan 03 2019, 1:56 PM
PhillipB	Updated DPLL on MCU Series 1 on Knowledge Base Question What is the usage of DPLL? Answer The Digital Phase-Locked Loop (DPLL) uses the HFRCO to generate a clock as a ratio of a reference clock source. The reference clock source (FREF) can be HFXO, CLKIN0, LFXO, or USHFRCO (if available). Output frequency = FREF(N+1)/(M+1), where N and M are 12-bit values in CMU_DPLLCTRL1 register. The DPLL is not available on EFM32xG1 and EFR32 devices. Code example on EFM32PG12: // Enable LFXO and wait it ready, use as DPLL reference clock CMU_OscillatorEnable(cmuOsc_LFXO, true, true); // Setup target HFRCO frequency, factor N and M CMU_DPLLInit_TypeDef dpllInit = CMU_DPLL_LFXO_TO_40MHZ; dpllInit.frequency = 36864000; dpllInit.n = 2249; dpllInit.m = 1; // CMU_DPLLLock() will update flash wait state and SystemCoreClock for target HFRCO frequency if (!CMU_DPLLLock(&dpllInit)) { // DPLL lock failed while (1); } Note: See "Specifications for External Clock Input via CLKIN0" for more information on CLKIN0* Show more	Sep 27 2018, 8:44 PM
PhillipB	Updated CLKIN0 on MCU Series 1 on Knowledge Base Question What is the usage of CLKIN0? Answer It is possible to configure the CMU to input a clock from the CLKIN0 pin. This clock can be selected to drive HFSRCCLK and DPLL reference using CMU_HFCLKSEL and CMU_DPLLCTRL respectively. The required input pin must be enabled in the CMU_ROUTEPEN register and the pin location can be configured in the CMU_ROUTELOC1 register. The CLKIN0 pin is not available on EFM32xG1 and EFR32xG1 devices. Code example on EFM32PG12: // Select HFSRCCLK on CLKOUT1 CMU->CTRL &= ~_CMU_CTRL_CLKOUTSEL1_MASK; CMU->CTRL \|= CMU_CTRL_CLKOUTSEL1_HFSRCCLK; // Enable CLKOUT1 on PD10 to monitor the HFSRCCLK CMU_ClockEnable(cmuClock_GPIO, true); GPIO_PinModeSet(gpioPortD, 10, gpioModePushPull, 0); CMU->ROUTEPEN \|= CMU_ROUTEPEN_CLKOUT1PEN; CMU->ROUTELOC0 \|= CMU_ROUTELOC0_CLKOUT1LOC_LOC4; // Enable CLKIN0 on PB6 GPIO_PinModeSet(gpioPortB, 6, gpioModeInput, 0); CMU->ROUTEPEN \|= CMU_ROUTEPEN_CLKIN0PEN; CMU->ROUTELOC1 \|= CMU_ROUTELOC1_CLKIN0LOC_LOC3; // Make sure the related wait state settings are correct and // CLKIN0 siganl is stable before switching the HFSRCCLK to CLKIN0 CMU->HFCLKSEL = CMU_HFCLKSEL_HF_CLKIN0; // Update system clock variable in according to CLKIN0 frequency SystemCoreClock = 8000000; Note: See "Specifications for External Clock Input via CLKIN0" for more information on CLKIN0 Show more	Sep 27 2018, 8:44 PM
PhillipB	Updated DPLL on MCU Series 1 on Knowledge Base Question What is the usage of DPLL? Answer The Digital Phase-Locked Loop (DPLL) uses the HFRCO to generate a clock as a ratio of a reference clock source. The reference clock source (FREF) can be HFXO, CLKIN0, LFXO, or USHFRCO (if available). Output frequency = FREF(N+1)/(M+1), where N and M are 12-bit values in CMU_DPLLCTRL1 register. The DPLL is not available on EFM32xG1 and EFR32 devices. Code example on EFM32PG12: // Enable LFXO and wait it ready, use as DPLL reference clock CMU_OscillatorEnable(cmuOsc_LFXO, true, true); // Setup target HFRCO frequency, factor N and M CMU_DPLLInit_TypeDef dpllInit = CMU_DPLL_LFXO_TO_40MHZ; dpllInit.frequency = 36864000; dpllInit.n = 2249; dpllInit.m = 1; // CMU_DPLLLock() will update flash wait state and SystemCoreClock for target HFRCO frequency if (!CMU_DPLLLock(&dpllInit)) { // DPLL lock failed while (1); } Note: See "Specifications for External Clock Input via CLKIN0" for more information on CLKIN0* Show more	Sep 27 2018, 8:44 PM
PhillipB	Posted Specifications for External Clock Input via CLKIN0 on Knowledge Base Question: What signals can be used to drive the CLKIN0 input on Series 1 MCUs (EFR32/EFM32) devices on which it appears? Answer: Some EFR32 and EFM32 Series 1 MCU devices support a CLKIN0 input to the CMU module, as depicted below - taken from Figure 10.1 "CMU Overview - High Frequency Portion" of the EFM32PG12 Reference Manual: The purpose of the CLKIN0 input path is two-fold, depending on what is implemented on a particular MCU device. CLKIN0 supports a low-frequency (<= 1 MHz) square wave clock input which can be used: to clock the device from an external CMOS source (BLUE path above), or by the DPLL as a reference clock (GREEN path above) For guidance on how to implement either of these configurations, see the following Knowledge Base articles: "CLKIN0 on MCU Series 1" "DPLL on MCU Series 1" Show more	Sep 27 2018, 8:42 PM
PhillipB	Updated Calibrating the Low-Frequency Oscillator (LFOSC0) on EFM8 on Knowledge Base 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" Show more	Sep 26 2018, 9:30 PM
PhillipB	Posted Calibrating the Low-Frequency Oscillator (LFOSC0) on EFM8 on Knowledge Base 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"). Show more	Sep 26 2018, 9:26 PM
PhillipB	Updated Updating the Watchdog configuration on EFM8 on Knowledge Base Question: Are there any restrictions that impact when the Watchdog Timer (WDT) can be configured? Answer: Yes. 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. See KB article "Synchronization when writing to Watchdog Timer Control (WDTCN) on EFM8" for insight on when you can be certain the WDT is disabled. Show more	Sep 25 2018, 9:57 PM

Level 6

Level 5

Following 0

Followers 1

Bojim