This tutorial requires a basic understanding of Connect Direct Mode. See Connect Tutorial Series: Table of Contents for an overview of Connect basics.
To conduct the following exercises, you'll need two Wireless Starter Kit (WSTK) boards, each equipped with a (preferably identical) radio board. The example application relies on CLI through the WSTK VCOM (over USB) port to issue commands and display status information.
EM4 is the lowest possible energy consumption mode of EFR32 devices. Wake-up from EM4 is practically equivalent with wake-up from reset, thus all the initialization steps must be executed, including clock and peripheral configuration, no data retentions. However, this enables the device to reduce current consumption as low as a few tens of nanoamps.
A further limitation of EM4 is that only GPIO pin wake-up is available and only five hardwired pins capable of wake-up the device. These pins are:
For more detailed information see the reference manual of the specific device
Although, Connect supports low power operation by enabling the
Idle/Sleep plugin - it only supports EM2 (in this mode the minimum current consumption is about 2-4uA). To exploit EM4 capability the low power mode must be implemented at the application level using the energy mode support APIs. The drawback of using EM4 with Connect is that the whole initialization process must be executed on wake-up - which in case of Connect stack takes around 200ms until the application code can be executed which have to be considered when planning the application architecture.
The example setup requires two units (WSTK + radio board), one will be the "keyfob" which sends a message on pressing the PB1 button on the WSTK to the other unit, the "controller" which will receive the message and print it on the UART console. The controller is a simple Connect Direct Mode application explained in detail in the above mentioned Connect Tutorial Series. The keyfob implementation uses the same Connect feature set but it is extended with the minimal EM4 specific configuration and one API call to enter EM4 mode.
In this current example set the keyfob sends a single message (with the payload
0x00) to the controller which toggles LED0 on received message and prints the payload on the UART console then acknowledges the message. The keyfob enters to EM4 if the ACK was successfully received or there is no incoming ACK after the retransmissions of the message (the default is three retries). The keyfob enters EM4 immediately if the wake-up button was not sensed (for example if the reset caused by an interruption in the power supply).
Silabs radio boards are equipped with an external SPI flash memory which is powered from the same rail as the EFR32. This flash memory is not in low power mode after the supply voltage is applied and the current consumption in this mode is roughly 8-10uA - which is two magnitudes higher than the overall current consumption we expect. The onboard flash has a deep power-down mode in which mode its current consumption is negligible, however, it requires to enable the driver from Connect HAL and call the initialization and entering into low power mode commands. Thus the example enables the
SPI flash plugin in AppBuilder and calls the following two API functions:
This is not necessary on custom hardware without this flash memory attached, so the two lines above should be commented out / deleted and the
SPI flash plugin disabled.
The default path of the execution results in (almost) immediate entering to EM4 when the device starts. If the device is in sleep mode the debugger cannot connect to the chip. To avoid locking the debugging checking of PB0 state is implemented to keep the device running. If the device is already programmed and a new firmware should be uploaded, press and hold PB0 during pushing the reset button on the WSTK board. This part of the code is only added to facilitate the development and can be safely eliminated in further phases. If the device enters into sleep mode right after start-up it is possible to recover from that state in Simplicity Commander by applying 'Unlock debug access' - although this erases the whole flash memory of the device.
The following snippet is the only necessary code to configure the device to enable EM4 mode:
GPIO_PinModeSet(BUTTON_WAKEUP_PORT, BUTTON_WAKEUP_PIN, gpioModeInputPullFilter, 1); EMU_EM4Init_TypeDef em4init; em4init.em4State = emuEM4Shutoff; em4init.retainLfxo = false; em4init.retainLfrco = false; em4init.retainUlfrco = false; em4init.pinRetentionMode = emuPinRetentionEm4Exit; EMU_EM4Init(&em4init); GPIO_EM4EnablePinWakeup(GPIO_EXTILEVEL_EM4WU1, 0); // PF7
The first line configures PF7 (PB1) as input. EM4 init parameters are mostly straightforward, retention mode
emuPinRetentionEm4Exit is set to reset pad state only after exiting EM4 mode. Finally, the last line enables wake-up on PF7 low level.
After the configuration is done, the application can enter EM4:
Before entering into EM4 it is advisable to clear pending GPIO interrupts.
The following screenshot shows a wake-up cycle
Measuring of current in nanoamps range is challenging, especially if it dynamically changes from several microamps to a few tens of nanoamps. Although, there is a current measurement capability of the WSTK and there is built-in Energy Profiler utility in Simplicity Studio, unfortunately, it is not precise enough to measure correct values in the low ranges. In the current example, the EM4 consumption measured by the WSTK was around a few hundreds of nanoamps. This is not only due to the precision of the current measurement but also because of several I/O lines of the chip connected to multiple lines/peripherals on the WSTK board itself.
Measuring the sleep mode current by precision current meter gives ~50-60nA which is close to the theoretically expected current consumption.
Exploiting of EM4 very low current consumption is reasonable when the device spends a long time in sleep mode which compensates the extra energy and time of wake-up from a reset-like state. These kinds of applications can be keyfobs for example where the devices wake-up only a few times a day and spend their lives in the lowest possible power mode most of the time.
If the devices were used with connect applications previously and the network was configured, the hardwired addresses / PAN ID will not be applied. In this case, a full flash erase is should be applied for correct operation.