The AEM (Advanced Energy Monitoring) is a feature built into all the EFM32 and EFR32 kits that allows real-time monitoring of the consumed current. On a PC, the Energy Profiler tool in Simplicity Studio can be used to plot the current consumption, average over time, zoom in and out to find peaks etc.
Out of the box, the AEM measures the consumption of the on-board MCU, but it can easily be used to measure the consumption of an external board as well.
Step 1 - Put the on-board kit MCU in Energy Mode 4
Flash the 'emode' demo found in Simplicity Studio to the kit MCU. With the push buttons on the kit, select EM4. This will cause the on-board MCU to stay in EM4 and consume only 20 nA of current, thus not influencing the measurement.
Step 2 - Power target board from the kit
Power your board from the VMCU/GND as shown below. It is important that you use VMCU and not 3.3V on the EXP header, as only the VMCU domain is measured. The SWO pin is optional and only needed if the code trace feature is used.
Note that the accuracy of AEM, especially at low current consumption, has some limitations.
7.3 Accuracy and Performance
The Advanced Energy Monitor is capable of measuring currents in the range of 0.1 μA to 50 mA. For currents above 250 μA, the AEM is accurate within 0.1 mA. When measuring currents below 250 μA, the accuracy increases to 1 μA. Even though the absolute accuracy is 1 μA in the sub 250 μA range, the AEM is able to detect changes in the current consumption as small as 100 nA. The AEM produces 6250 current samples per second.
For more information about AEM, see the user's guides for any of our starter kit boards.
For information about measuring current for low energy devices, check out this application note, the content applies to any 32 bit MCU.
Sometimes it is possible to lose debug access to the MCU, unintentionally. A few examples include
If any of the above are done early in the program, a debugger will not have time to halt the MCU before it loses access.
There is a process for regaining debug access. When an EFM32 is reset, there is a small window where a module called Authentication Access Port (AAP) is connected to the debug interface. This window is 47 µs long and occurs right before the core starts executing code.
A debugger can use the AAP to initiate a Mass Erase, which will erase the entire main flash block, SRAM and the Lock Bits Page and give back debug access. This process is referred to as 'Debug Unlock' because it is the same method that is used to re-obtain debug access when the debug interface has been locked intentionally.
An EFM32 kit (STK/DK) must be used as a debugger to execute Debug Unlock. The unlock feature is not built into third party probes. See this guide for how to use a kit as debugger for your board. If you are debugging the on-board MCU on a kit, Debug Unlock works as well.
To execute Debug Unlock, open the energyAware Commander from Simplicity Studio and click the 'Debug Unlock' button in the Flash tab.
Note: energyAware Commander is no longer available, but many of the features originally found in this utility are now available elsewhere within Simplicity Studio. The "Debug Unlock" feature is now accessible in two locations:
1) from within the Simplicity Commander tool (more information in this KB article: Simplicity Commander) as depicted below:
2) a slightly different unlock algorithm is implemented in the [Flash Programmer] utility - which is one of the tiles that appears on the Simplicity Studio home/launcher screen when a debugger is connected - as depicted below:
Stubborn locked/bricked MCU devices (particularly those that reside on your own board) may respond better to this unlock utility than that within Simplicity Commander, or vice versa.
Simplicity commander also has a command line utility with a set of recovery techniques available in "device recover" command. Documentation for the command line utility is found in UG162. To execute this command open a terminal and enter the following:
cd C:\SiliconLabs\SimplicityStudio\v4\developer\adapter_packs\commander commander adapter dbgmode OUT commander device recover --device NAME_OF_TARGET_DEVICE
The process takes a few seconds. After this, reconnect with the Commander and make sure the 'MCU Information' is visible on the Kit tab. If the MCU Information screen shows 'Not Connected' the debugger does still not have access. In case it doesn't work check that
In Simplicity Commander, this appears as:
As with the "Unlock Debug Access" feature, the Debug Mode is also now depicted in a second location within Simplicity Studio - in the [Kit Manager] tool:
For more information about the debug interface and the AAP, please see AN0062 in Simplicity Studio.
This article applies to EFM32 Series 0 devices:
Every EFM32 Series 0 device is assigned a 64-bit Unique ID, which is programmed into the Device information page of the flash during the production of the device.This 64-bit value is guaranteed to be unique for all past and future EFM32 Series 0 device that are manufactured.
The 64-bit value can be read from the following addresses:
UNIQUE_0 is a 32-bit timestamp (Unix time) set during production
UNIQUE_1 is a 32-bit value that represents the facility ID where the part was produced.
As each facility does not produce more than one part per second (smallest resolution of the timestamp), the two values together constitute a 64-bit unique number when combined.
Note that Silicon Labs while reserves the right to change the structure of these values in the future, but the uniqueness will still be guaranteed.
Hashing the Unique ID to generate smaller ID values
While uniqueness is only guaranteed when using the full 64-bit value, smaller IDs can be generated by using a cryptographic hashing function to reduce the ID bit number while still maintaining a low probability that two or more IDs will be identical. A hash function has a diffusion property that every bit of its input affects on average half of the bits of the output. Hashing the ID and then discarding bits will result in a collision probability directly related to the effective reduction in bit count.
Given that we generate k hash values where each value is a non-negative integer less than N, the probability that at least two of them are equal can be shown to be approximately:
The approximation is valid only if k is a lot smaller than N.
If a 56 bit hash value is generated from the Unique ID, there would then be a k(k-1)/(2*2^56) probability that at least two values would collide. If we assume that we generate k=1e6 values, the probability of collision is 6.93e-6.
Many cryptographic hashing functions could be suitable for this application, but when using an EFM32 the on-chip AES accelerator provides a speed benefit over other pure SW solutions. The AES accelerator can be used by combining the 64-bit UNIQUE ID together with an arbitrarily chosen constant to be used as the 128-bit data input to the AES function. The 128-bit key could also be an arbitrarily chosen constant. n bits of the output of the AES encryption can then be chosen to represent a pseudo unique ID with the collision probabilities described above.