Can you provide some information about how long it takes for the TRNG to start outputting data, particularly after exiting a low energy mode?

As shown in this diagram...

...the TRNG (True Random Number Generator) consists of several sub-blocks that operate together to generate cryptographically secure random numbers. Each of these sub-blocks takes a certain number of clock cycles to do its part of the process.

The "random" part of the TRNG is provided by ring oscillators that make up the entropy source and run asynchronously to the rest of the system. Because the entropy source is asynchronous, we can speak of it in a way similar to an analog-to-digital converter in that its output is "sampled" by the upstream sub-blocks in the TRNG, the clock for which is the HFPERCLK.

So, once the power is supplied, the entropy source begins running, but, naturally, needs some time to "warm-up" before its output is sufficiently random. This start-up delay is determined by the TRNG_INITWAITVAL register and defaults to the maximum possible 256 clocks, which should not be reduced.

How exactly do we know that the output from the entropy source is "sufficiently random?" Obviously, just assuming that 256 clocks is enough because it's the maximum possible value for a register does not sound particularly robust. Instead, the TRNG includes sub-blocks which test if the output of the entropy source meets standards of cryptographic randomness. Specifically, these sub-blocks execute the National Institute of Standards repetition count and adaptive proportion tests with window sizes of 64 and 4096 bits, respectively, as described in standard NIST-800-90B and the Bundesamt für Sicherheit in der Informationstechnik online test described in AIS 31. These tests run in parallel such that the associated delay is 4096 clocks because of the 4096-bit adaptive proportion test.

Whitening, which is the conditioning of the entropy source output to reduce bias and correlation, occurs after the integrity tests run.  This takes 128 clocks and is enabled by default because the TRNG_CONTROL register CONDBYPASS = 0 out of reset.
 

Filling of the output FIFO is the last step in the start-up process and takes 64 words × 32 clocks (bits) / word = 2048 clocks.

Summing up these components, we see that the TRNG takes...

256 (INITWAITVAL) + 4096 (entropy tests) + 128 (whitening) + 2048 (FIFO fill) = 6528 clocks

...which would be about 344 µs at the default HFRCO frequency of 19 MHz.

This delay is incurred not only when the module is first enabled but also upon wake-up from the EM2 and EM3 low-energy modes. Sampling of the entropy source, integrity testing, output whitening/conditioning, and, of course, the output FIFO all run from the HFPERCLK, which, along with the entropy source itself, is disabled in EM2 and EM3. Upon wake-up, all of these must restart, thus necessitating the delay.

Giant Gecko 12 deviates from the figure presented above. Its TRNG_INITWAITVAL register defaults to 1024 instead of 256, yielding a net delay of 1024 (INITWAITVAL) + 4096 (entropy tests) + 128 (whitening) + 2048 (FIFO fill) = 7296 clocks.

I see in the CMU chapter that two clocks are present for the PDM (Pulse Density Modulation) interface. There is HFCLK_PDM and HFPERCLK_PDM. what is the difference between these two clocks as their names are very similar?

Despite their similar names and use by the PDM interface, the HFCLK_PDM and HFPERCLK_PDM have entirely different purposes. HFCLK_PDM is the clock source for the PDM receiver core just as a synchronous serial audio interface (e.g. I2S/SSI) will have its own specific clock that is usually some multiple of the audio sampling clock.  The CMU PDM Control Register (CMU_PDMCTRL) allows you to select this clock , which can be asynchronous to the main system clock. In Figure 42.1 of the Giant Gecko 12 Reference Manual, this is the clock labeled hfpdm_clk.

HFPERCLK_PDM is the PDM module bus clock. It clocks all of the register and power management logic in the PDM block. You would disable the PDM module by disabling the HFPERCLK_PDM in the CMU_HFPERCLKEN0 register, which is the reset state when you power up. Before the PDM can be used, you must enable HFPERCLK_PDM, then enable HFCLK_PDM.

Abbreviations

• KBA - Knowledge Base Article
• SDIO Driver - Low level software package for SDIO and SD Card
• Host Spec - SD Host Controller Simplified Specification Ver3.00 standard Jump to the Standard
• Card Spec - Physical Layer Simplified Specification Ver 6.00 Jump to the Standard

Short introduction

The purpose of this KBA is to make an initial, low level function library (hereinafter: SDIO driver) for the SDIO peripheral of the EFM32GG11B Giant Gecko STK and then a short example code will demonstrate its operation. Furthermore, this KBA's primary role is to give a good base for further development and it can perform easy operations between memory card and the MCU. Low "level function" means that the SDIO Driver uses just the MCU and the SDIO peripheral related registers and the implemented example will not use higher level software, e.g.: FAT handler software package. Initial means that the implementation from SD Host Controller Simplified Specification Ver3.00 (hereinafter: Host Spec) and from the Physical Layer Simplified Specification Ver 6.00 (hereinafter: Card Spec) is not holistic. In other words, the necessary relevant parts of the previously mentioned specifications are implemented. The further sections will describe these parts.

Figure 1 - High Level description

Figure 1 gives a high-level schematic about the used things (HW and SW) and newly implemented codes. The previously available things are marked with grey color and what this KBA implements are marked with green and orange color.

What can the reader expect from the example code

The whole example section is realized in the 'main.c' file. This example will perform basic, low level operations between the MCU and the memory card. Basic means that for addressing the memory card, the example code will use direct SD card section's address to perform the write and read operations (no FAT table).

What can the reader expect from the SDIO driver

The reader will get an initial, low level driver for the SDIO host and for the memory card with the following features:

• 4 lines DATA width for read/write operation
• adjustable SD clock speed (tested on 100kHz and 400kHz)
• uses processor to read/write data (no DMA)
• for read/write operations the software uses single section read/write functionality
• does not support SDIO devices (e.g.: SDIO Bluetooth, GPS)

Description of the SDIO driver

Base information for the proper understanding and for further development is that the EFM32GG11B related SDIO peripheral and the SDIO host peripheral (which is described in the Host Spec) are the same peripheral. Therefore, you can use Host Spec documentation for using the SDIO peripherals. It is good news for developers because the efm32gg11b reference manual's section about the SDIO peripheral is just 60 pages, but Host spec is much more, nearly 160 pages. Both specifications (Host Spec and Card Spec) give a very good and easily understandable description about the operation of the SDIO and the memory card. Therefore, the primary role of this chapter is not copy paste sections from the specifications. Instead of that, it will give a passage between the implemented SDIO driver and the used specifications.

The SDIO driver can be logically divided to 2 sub drivers

• SDIO host driver
• SD card driver

The SD card driver is mostly the memory card command related items in the source code (e.g.: CMD24 macro). The SDIO host driver related items are mostly the 'Sequences' which are defined in the Host Spec on page 92. The border between SDIO host and SD card drivers is melted because both document describe the same sequences, but the descriptions are based on different point of view.

Function structure of the SDIO Driver

The SDIO driver has 2 types of functions:

• public
• private

This kind of classification helps for developers/users which functions are necessary for using of SDIO Driver and which ones contribute for the inner operation of the SDIO Driver. In case of using, the user can see which functions are developed in order to using (public functions) and which functions performs inner operation (private functions, these functions are not directly usable functions). In case of development, the developer can see which functions inner functions are and they can easily modify/delete/create these kinds of functions.
The private functions cannot be called from outside of the SDIO driver. These functions contribute to the simplicity of the module, perform inner mechanism which based on the state of the SDIO/SD registers, etc. Naming convention of these functions is: SDIO_S_comprehensive_name. The public functions can be called from outside of the SDIO driver. These functions realize main desired functionalities. Naming convention of these functions is: SDIO_comprehensive_name. Generally, these functions call and schedule the driver related private functions. The following functions are public functions

• SDIO_Init()
• SDIO_WriteSingleBlock()
• SDIO_ReadSingleBlock()
• SDIO_GetActCardStateType() - (this function will not be used in this example)

The following mapping table (Table 1) will help to establish the connection between the functions of the SDIO driver and the Host/Card Specs.

Table 1 - Mapping Table

Short description about the public functions

void SDIO_Init()

The goal of this function is to initialize the MCU related SDIO peripheral, initialize the SD card and at the end modify the state of the SD card from standby to transfer mode. In transfer mode the SD card can write and read its sections.

void SDIO_ReadSingleBlock() and void SDIO_WriteSingleBlock()

The function will initiate a single read or write operation between the SD card and the MCU. Both functions have 3 parameters:

• SDIO register's address
• SD card related block address
• MCU related memory address

Independently of the direction of the operation, the amount of the data will be 512 bytes which is implemented in the SDIO_Init() function. For the read/write operation the MCU will use its CPU - no DMA support, but it also can be implemented in the SDIO_Init() function.

Description of the example code

Bullet points about the operation:

• reserves 1024byte area from the MCU's RAM
• this reserves area will be filled with 'F' characters
• general MCU initialization
• initialize STK according to use soldered micro SD card slot
• initialize SDIO host and memory card
• Write to memory card (512byte data from reserved memory area)
• Read from memory card (to reserved memory area)
• previous 2 points again

User guide for the example code

• import the project to Simplicity Studio
• insert a memory card to the SD socket of BRD2204A (ATTENTION! MAKE BACKUP BEFORE THE USING OF MEMORY CARD! THE CONTENT OF THE MEMORY CARD CAN BE SPOILED!)
• attach BRD2204A development board to your computer
• start project in Debug mode
• insert break points to the main.c file (around read/write operations)
• check the content of the reserved MCU's RAM array
• at the end check the content of the memory card (insert the memory card to a card reader and check the content with a hex viewer)

At the end of the execution the reserved ram area of the MCU will be filled with the content of the selected memory card's data and the memory card's selected pages will be filled with the content of reserved memory's content. (in the case of example with 'F').

Tested configuration

• Board: EFM32GG11B STK - BRD2204A Rev BD4
• Windows 10 operaion system
• Simplicity Studio V4.
• 32-bit MCU SDK Version: 5.6.1.0
• SD Cards:
  • Samsung MB-MA080 (8GB, SDHC, 6)
  • No name (32GB, SDHC)

Here is an erroneous use case, user intend to set debug lock bits by locating a constant at DLW.

1. Add a LOCKBITS memory region in ld file, and then create a new section called .dlwLockBits.

MEMORY
{
	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 262144
	RAM (rwx) : ORIGIN = 0x20000020, LENGTH = 32660 
	LOCKBITS (rwx) : ORIGIN = 0x0FE04000, LENGTH = 2048
}
…
  __etext = .;
  
  .dlwLockBits :
  {
    . = . + 508;
    KEEP(*(.dlwLockBits))
  } > LOCKBITS
…

…
const uint32_t debugLockWord __attribute__ ((section (".dlwLockBits"))) = 0;
…

Fill the section with the initial value 0xFF can avoid the AAP lock. In case that user need to keep some lock bits(like user page lock) should not use this method.

MEMORY
{
	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 262144
	RAM (rwx) : ORIGIN = 0x20000020, LENGTH = 32660 
	LOCKBITS (rwx) : ORIGIN = 0x0FE04000, LENGTH = 2048
}
…
  __etext = .;
  
  .dlwLockBits :
  {
    . = . + 508;
    KEEP(*(.dlwLockBits))
  } > LOCKBITS = 0xFF
…

MEMORY
{
	FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 262144
	RAM (rwx) : ORIGIN = 0x20000020, LENGTH = 32660 
	LOCKBITS (rwx) : ORIGIN = 0x0FE041FC, LENGTH = 4
}
…
  __etext = .;
  
  .dlwLockBits :
  {
    KEEP(*(.dlwLockBits))
  } > LOCKBITS
…

But it’s not recommended to set debug lock bits in this way. We have a debug lock example (msc\debug_lock) below demonstrates how to lock the debug interface by clearing debug lock bits.

https://github.com/SiliconLabs/peripheral_examples.

Question: How do I configure the ADC to use in EM2 and EM3 mode?

Answer: The following conditions must be met:

1. ADC must be clocked by AUXHFRCO.
2. ADC must operates in asynchronous mode.
3. HFPERCLK must be at least 1.5 times higher than the ADC_CLK (so AUXHFRCO).

If the chip enters EM2/EM3 mode when ADC is busy without using AUXHFRCO, then the ADC clock will stop but the ADC will stay on, resulting in higher supply current. If this occurs, the EM23ERR interrupt flag will be set.

For EM2 DeepSleep or EM3 Stop operation of the ADC, the ADC_CLK must be configured for AUXHFRCO as this is the only available option during EM2 DeepSleep or EM3 Stop. The ADC_CLK source should not be changed as the system enters or exits various energy modes, otherwise measurement inaccuracies will result.

The following example code initializes the ADC as reqired for EM2/EM3 mode:

 void initADC(void) {
  // Enable ADC0 clock
  CMU_ClockEnable(cmuClock_ADC0, true);
   // Select AUXHFRO band
   CMU_AUXHFRCOBandSet(cmuAUXHFRCOFreq_1M0Hz);
   // Select AUXHFRCO for ADC ASYNC mode so that ADC can run on EM2
   CMU->ADCCTRL = CMU_ADCCTRL_ADC0CLKSEL_AUXHFRCO;
   // Make this change to ensure the AUXHFRCO is selected
   ADC0->CTRL = ADC_CTRL_ADCCLKMODE_ASYNC;

  // Declare init structs
  ADC_Init_TypeDef init = ADC_INIT_DEFAULT;
  ADC_InitSingle_TypeDef initSingle = ADC_INITSINGLE_DEFAULT;

  // Modify init structs and initialize
  init.prescale = ADC_PrescaleCalc(40000, 0);
  init.em2ClockConfig=adcEm2ClockOnDemand;

  initSingle.diff = false; // single ended
  initSingle.reference = adcRef2V5; // internal 2.5V reference
  initSingle.resolution = adcRes12Bit; // 12-bit resolution
  initSingle.acqTime = adcAcqTime4; // set acquisition time to meet minimum requirements

  // Select ADC input. (PE11 -> EXP header pin 6)
  initSingle.posSel = adcPosSelAPORT4XCH11;

  ADC_Init(ADC0, &init);
  ADC_InitSingle(ADC0, &initSingle);

  // Enable ADC Single Conversion Complete interrupt
  ADC_IntEnable(ADC0, ADC_IEN_SINGLE);

  // Enable ADC interrupts
  NVIC_ClearPendingIRQ(ADC0_IRQn);
  NVIC_EnableIRQ(ADC0_IRQn);
}

Related articles: ADC in async mode | ADC with AUX clock

Questions:

A. What is Errata RMU_E103

B. What devices are affected?

C. How can I prevent this issue from affecting my application?

D. Are there plans to fix this issue?

Answers:

A.

Erratum RMU_E103 describes an issue with certain Series 0 EFM32 devices. Affected parts see a gap in the coverage of the brown-out and power-on reset sources around 1.3V . The exact gap in reset coverage will be part specific if present at all. If an affected device is operating in this problematic VDD range, the device will attempt to start up while well below the tested supply voltage for the microcontroller.

The device takes a short amount of time to start up. For a typical part at normal voltages this is 163 µS. If the startup succeeds, the device will then attempt to execute code, but may not be able to do so at low voltage. At this low voltage neither a successful startup or successful code execution is guaranteed.

Note that during fast voltage ramps, e.g. power-on and power down events, VDD will not be at a problematic voltage long enough for the device to start up. However, if VDD is held at around 1.3V for a sufficient duration, the device may enter this undefined state where code is being executed below tested voltages.

The workaround to this issue is to assert a pin reset during the low VDD event. If a pin reset is asserted, the device cannot attempt to start up. The reset pin should be driven low prior to VDD falling below the BOD reset threshold.

B.

RMU_E103 is an erratum that effects some devices from the following EFM32 Series 0 products:

• EFM32 Zero Gecko
• EFM32 Happy Gecko
• EFM32 Wonder Gecko
• EFM32 Leopard Gecko
• EFM32 Tiny Gecko (Series 0 only)
• EZR32 Happy Gecko
• EZR32 Wonder Gecko
• EZR32 Leopard Gecko

This erratum does not affect EFM32 Gecko, Giant gecko, or any EFM32 Series 1 devices.

C.

Steps can be taken to both detect if RMU_E103 is occurring on a specific device, and to prevent code from executing at low voltage.

• To detect a gap in reset source coverage, Measure the current consumption of the device while gradually lowering VDD. If the device attempts to start up at low voltage, current consumption will increase. The diagram below shows an example VDD waveform that can test for code execution at low voltage and the corresponding spike in current consumption. Note that the current and voltage values are approximate and will vary across parts, applications, and environments.

Figure 1. VDD Test for RMU_E103 Current Consumption

• To avoid code execution at low voltage, avoid slow VDD ramps during normal operation. If the application is likely to experience a slow VDD ramp or see low supply voltage for any significant duration of time, use an external device or user input to assert a pin reset at some VDD level > 1.96V (with sufficient time to engage the internal reset before VDD reaches 1.96V).

Questions:

A. What is Errata RMU_E102?

B. What devices are affected?

C. How can I prevent this issue from affecting my application?

D. Are there plans to fix this issue?

Answers:

A.

Erratum RMU_E102 describes an issue with certain Series 0 EFM32 devices. Affected parts may see voltage regulator failure when subjected to the following scenario:

1. VDD begins to fall due to some external event
2. VDD and Regulator output (DECOUPLE) voltage decay to 0.8-1.2V
3. Power supply to VDD is restored and VDD returns to a nominal value  prior to VDD and DECOUPLE reaching < 0.8V 

In this type of sequence mentioned above , the voltage regulator may fail to re-initialize. If this occurs, the DECOUPLE pin will continue to decay to 0V, even after VDD has recovered. In this state, the core logic is not powered, and the device will be unable to execute code or respond to a pin reset. An affected device will successfully recover from this state if power cycled.

Additionally, if a pin reset is applied prior to the Brown out detector (BOD) asserting reset, the regulator will always re-initialize successfully. The BOD threshold varies between 1.74-1.96V, so a pin reset should be asserted before VDD drops below 1.96V. The pin-reset should be held low until VDD is >1.98V, which is the maximum power-on reset threshold.

The diagrams below demonstrate an example VDD waveform that can cause the regulator initialization to fail.

Figure 1. VDD Decay and Recovery

This figure shows the proper recovery sequence, or what will happen to a working device (not affected by RMU_E102) when VDD falls to 0.9V. Here, the regulator restarts after VDD is restored, and the DECOUPLE voltage returns to 1.8V.

Figure 2. VDD Decay and DECOUPLE failure

This figure shows the failure mode for a device affected by RMU_E102 when VDD falls to 0.9V. As you can see the regulator fails to re-initialize properly, and the DECOUPLE voltage continues to fall until reaching 0V. At this point a power-on reset must be performed to recover the device.

As mentioned above, there are two workarounds to the issue.

• For a device that is already in lock-up, perform a power cycle to recover to a normal state. To do this VDD must be driven to 0V before powering back on.
• For a device that may experience a drop in VDD to 0.8-1.2V, use an external device or user input to assert a pin reset at some VDD level > 1.96V (with sufficient time to engage the internal reset before VDD reaches 1.96V). Additionally, the reset should be held low until power is reconnected and VDD is greater than 1.98V.

B.

RMU_E102 is an erratum that effects some devices from the following EFM32 Series 0 products:

• EFM32 Zero Gecko
• EFM32 Happy Gecko
• EFM32 Wonder Gecko
• EFM32 Leopard Gecko
• EFM32 Tiny Gecko (Series 0 only)
• EZR32 Happy Gecko
• EZR32 Wonder Gecko
• EZR32 Leopard Gecko

This erratum does not affect EFM32 Gecko, Giant Gecko, or any EFM32 Series 1 devices.

C.

To avoid issues caused by RMU_E102, the following precautions should be taken.

• Avoid and check for intermittent battery or power supply connections to VDD. The issue was originally discovered in situations where a loose battery connection during assembly caused VDD to repeatedly drop to ~.9V and then recover to a nominal value. This represents a worst-case scenario for inducing RMU_E102, as multiple VDD disconnections occurred within a very short time frame.
• If your application is likely to experience frequent disconnects from the power supply, ensure that the reset pin is driven low prior to disconnecting.