This knowledge base article demonstrates low power operation of the EFM32TG11 using LESENSE to measure movement (rotations and direction) of a half metal disc, similar to what would be used in a water or gas meter. This article includes a software project, and schematic and layout files for an expansion board that connects to the EFM32TG11 STK (SLSTK3301A).
For more information on LESENSE and a software example for Series 0 devices, see AN0029: Low Energy Sensor Interface - Inductive Sense.

Hardware Design

This example uses the SLSTK3301A starter kit for the EFM32TG11, and a custom PCB that connects to the expansion header.  The board has two LC tanks, like the one on the STK, and a 3" half disc mounted to the board with RC car bearings and axles (Traxxas 5116 and Traxxas 6853X). There are also footprints to place two hall effect sensors (Si7204 or Si7210) under the disc, although theseare not implemented in this design.

The two tanks on the expansion board are driven by the main output of DAC0 CH0. These two tanks, and the one on the board share the excite pin (PB11). All tanks can be sampled in this configuration. To use PB11 as LESENSE_EXCITE, a wire needs to be connected to the lower half of R198, to a 100 ohm resistor. The other end of the resistor should be connected to W14. A 0.1 uF capacitor should also be connected from W14 to ground.

A third tank circuit is present on the STK. While it is not used to detect disc rotation, some tamper detection methods use a third tank, so the STK tank is measured to demonstrate that capability. When metal is detected next to this tank, a gecko symbol is drawn on the LCD screen.

The most power efficient settings are to have the DAC triggered by LESENSE. This way the DAC is only enabled when needed. Regular or alternate DAC outputs can be used. Routing the DAC signal through APORT is not recommended as the APORT has higher output impedance.

In order to reduce interference between the tanks, LESENSE pins that are not being scanned can be set to the DAC voltage. Since the tank is connected to the DAC on one side, setting the other side to the DAC voltage will result in no voltage drop across the tank. This reduces coupling between the tanks. This is accomplished by setting the channel idle mode to lesenseChPinIdleDACC. Note that this only works for pins that are an alternate output of the DAC channel being used. For DAC channel 0, this is PC0, PC1, PC2, and PC3. For DAC channel 1, this is PC12, PC13, PC14, and PC15.

Software Design

Once initialized, the main tasks of the application are handled by LESENSE without software execution. LESENSE can run in EM2 while clocked from the LFXO. LESENSE implements quadrature decoding with the decoder state machine. The decoder uses PRS to send signals to PCNT, which maintains the count of rotations. The main loop handles updating the LCD display (triggered from a periodic cryotimer interrupt), and detecting button presses to cycle through display modes.

The LESENSE module uses a sliding window to evaluate the output of the ACMP counter and convert the count into a binary result. This helps compensate for variations in the tank circuit (caused by variances in component values, for example) and removes the requirement that the tanks not be near metal when the device is calibrated.

Current Consumption

When scanning at 16 Hz and sampling 3 tanks, with the LCD off, the average current consumption is 3.5 uA. Enabling the LCD adds about 2 uA of current consumption to power the LCD as well as to do the calculations to generate the strings to display (sprintf).

In this configuration, the marginal consumption of an additional tank is about 100 nA. In cases where a tank needs to be sampled very infrequently, it may be feasible to have a periodic interrupt enable a channel and enable the decoder interrupt. During the decoder interrupt, the tank result can be measured, and the channel and decoder interrupt can be disabled until next time.

Tamper Detection

Only two tanks are required for quadrature decoding of a disc. Typically, half of the disc is made of metal and the tanks are placed 90 degrees apart. With only 90 degrees of the disc's rotation is monitored by the tanks, there is a period where the disc is not detected by either coil. Removing the disc entirely would be indistinguishable from the disc stopping in this position. This would allow unbilled use of the meter. To prevent this, a third tank can be used so that at least one tank is covered at any time. The third tank does not need to be
sampled as often as the first two. See the performance section for tradeoffs in sampling rate. It is also possible to implement a state machine that monitors more than two coils and has a state for tampering detected.

Debugging

Because most of the work this application does is handled by the LESENSE state machine, traditional debugging with breakpoints and stepping is not very effective. Components can be tested one stage at a time (LESENSE counts, scan results, decoder state, PCNT) by reading the registers, or directing the output to an IO pin (for example, PRS signals from the DECODER can be measured at IO pins to verify the DECODER is operating correctly, then the PRS signals can be sent to the PCNT module).

An oscilloscope is useful to monitor the tank oscillations, DAC output voltage, and timing of the excite signals. Note that the capacitance of the scope probe will have an influence on the circuit and may prevent it from operating normally. If a scope probe has multiple gain modes, the capacitance is typically less in the higher gain mode (this can be compensated for by the oscilloscope).

Putting the DAC into a lower power mode where it is driven infrequently can cause it to be more susceptible to noise or interference from scope probes or from pins being touched by a person. When diagnosing issues, the DAC can temporarily be set to continuous conversion mode to prevent these issues. Continuous conversion mode will have much higher current consumption.

Conclusion

This application was developed on an EFM32TG11 (Series 1). Porting to other Series 1 devices that have VDAC and LESENSE is straightforward. The firmware uses emlib for most of the configuration, ensure the availability of DAC alternate output on LESENSE pins.

The DAC peripheral has changed significantly since Series 0. For an example of LC sensing implemented on Series 0 see AN0029.  There are currently no Series 2 devices with LESENSE.

See AN0029 for a more detailed explanation of LESENSE and a software example for Series 0. See the software example SLSTK3301A_helges_demo for another software example that uses LESENSE on an EFM32TG11 STK to detect metal near the onboard tank of the STK.

Malloc is a function provided by the C standard library which is used to dynamically allocate memory. It uses a low-level memory management function, called sbrk, to determine if the heap has available space.  Silicon Labs provides a simple implementation of sbrk, designed for compatibility between all projects. Due to this, it can exhibit a strange behavior where calls to malloc will not return a NULL, even if the heap is full. If an application requires dynamic memory allocation, sbrk will need to be modified to prevent this issue.

 

For bare-metal applications:

A sample sbrk implementation, which should work with most MCU projects, is provided below. This implementation checks the MSP to determine how much stack space is available. To add this implementation to a project, open “retargetio.c”, which is usually found in the folder “hal-efr32”. Find the sbrk implementation within that file and replace it with the one found below.

#include <sys/stat.h>
extern char _end; /**< Defined by the linker */
caddr_t _sbrk(int incr)
{
  static char *heap_end;
  char *prev_heap_end;

  if (heap_end == 0) {
    heap_end = &_end;
  }

  prev_heap_end = heap_end;
  if ((heap_end + incr) > (char*) __get_MSP()) {
    //errno = ENOMEM;
    return ((void*)-1); // error - no more memory
  }
  heap_end += incr;

  return (caddr_t) prev_heap_end;
}

This example may not work for every example application since different applications configure memory differently. For example, the Bluetooth stack puts the stack at the beginning of RAM, so the MSP can not be used to determine the end of the heap. For this setup, you will need to use an sbrk implementation like the one below. This implementation uses "__HeapLimit", which is defined by the linker, to determine where the heap ends.

#include <sys/stat.h>
extern char _end;         /**< Defined by the linker */
extern char __HeapLimit;  /**< Defined by the linker */
caddr_t _sbrk(int incr)
{
  static char *heap_end;
  char *prev_heap_end;

  if (heap_end == 0) {
    heap_end = &_end;
  }

  prev_heap_end = heap_end;
  if ((heap_end + incr) > (char*) &__HeapLimit) {
    //errno = ENOMEM;
    return ((void*)-1); // error - no more memory
  }
  heap_end += incr;

  return (caddr_t) prev_heap_end;
}

In general, keep your application's memory layout in mind when using malloc, and modify sbrk to fit.

 

For RTOS applications:

The above implementations of sbrk can be used in a multi-threaded environment, but with the caveat that they are not thread-safe. This can be circumvented by wrapping calls to memory management functions in critical sections. Additionally, most RTOSes will provide implementations of dynamic memory allocation. For example, MicirumOS provides a memory management API that can be used instead of the standard library implementations.

1. Abbreviations

• SDK - Software Development Kit
• HAL - Hardware Abstraction Layer
• KBA - Knowledge Base Article
• ROS - Robot Operating System
• SLSTK, SLSTK3701A - Giant Gecko Starter Kit

2. Configuration

• Board:
  • EFM32GG11B STK - BRD2204A Rev BD4 (SLSTK3701A)
• Development:
  • Windows 10 OS
  • Simplicity Studio V4.
  • 32-bit MCU SDK Version: 5.6.1.0
• Execution:
  • Ubuntu 16.04 LTS
  • ROS Kinetic

3. Preface

The ROS is one of the most known robot platform which hobbyist uses for their robot projects. Furthermore, based on the ROS related widespread libraries, the user community, and the well-structured documentation, usage of the ROS expanded to the industrial participants too. ROS' name refers to an operating system, but it is not truly an operating system, instead, ROS is a framework which should be installed and configured to run on Linux operating system. The official ROS releases recommend that the developers should install these frameworks to one of Linux Ubuntu distros. As regards of the resource consumption of Ubuntu distributions, the ROS cannot be run on low resource based MCUs (like Cortex M, Atmel 8bit, etc.), so the developer should use appropriate devices to run Ubuntu. These devices can be regular PC's, laptops or board computers (e.g.: Raspberry Pi). At this point the reader probably has a question: why is it useful using of low power MCUs when the ROS cannot be run on them. And the answer is: these MCUs are used as expansions of the ROS’ host computer. An MCU can easily initiate a connection with a sensor, collect the data of this sensor and at the end send the collected data to the host PC where the data will be processed. The officially supported MCUs are listed on the ROS website, and it is also described how a not supported one can be added. This KBA will give a high-level description with an example about how EFM32 or EFR32 MCUs can be transformed to a ROS Serial Node.

4. What can the reader expect from this KBA

This KBA will not explain: ROS related base concepts. The readers who are not familiar with those words in ROS environment like roscore, node, topic, etc. should take the first steps on the ROS website. The intent of this KBA is describing the process of how a developer can append a not officially ROS supported MCU to ROS environment. The description will not start from the scratch: the ROS related chapter about how a new MCU can be added, the Arduino related source codes and the Silabs related SDK will be used for the development. The previously used "development" word can be divided to two parts: in the first part the ROS related hardware driver will be implemented, in the second part an available Arduino based ROS end node project will be ported to the previously implemented end node.

5. ROS serial node

The serial node's operation is very primitive: the communication between the host PC and MCU is performed via UART. This communication is defined by ROS, the ROS library has module which defines it. Before the MCU starts to exchange data between itself and the host PC, the MCU has to convert the data to a predefined structure, which called "messages". These messages also have modules in the ROS library, so they can be just used. The following picture will visualize the high-level structure of the implemented serial node.

Figure 1 - High level structure of ROS node SW

5.1 ROS library - HW linking layer

The description starts with the middle layer, because it is the key element contributing to the operation of the node. Check the following site for initial description: (http://wiki.ros.org/rosserial_client/Tutorials/Adding%20Support%20for%20New%20Hardware) All lower layers, software and hardware, shall be encapsulated into the following 4 methods, and upper ROS layers, like ROS library and ROS application will use these methods:

class Hardware
{

  Hardware();

  // any initialization code necessary to use the serial port
  void init(); 

  // read a byte from the serial port. -1 = failure
  int read()

  // write data to the connection to ROS
  void write(uint8_t* data, int length);

  // returns milliseconds since start of program
  unsigned long time();

};

The reader can find the SLWSTK3701 related class file in the attached project, with the following path and name: /ros_lib/ros/SLSTK3701AHardware.h. Another specialty of this layer is that it is a mixture of the c and the c++ programming language. The HAL layer has been written in C, but the ROS related layers require C++ methods and classes.

Explanation of the functions:

void init():

This method is responsible for the initialization of the hardware, the MCU and the MCU related peripherals. It has 2 mandatory items which shall be initialized:

• a TIMER peripheral, which will be the base of the time() method and
• an USART peripheral, which will be the base of read() and write() methods.

int read():

Read() method is responsible for receiving the data which has been sent by the host PC. The ROS Lib processes the received data in asynchronous mode, therefore the plain USART_Rx() function had to be expanded with a circular buffer. This buffer was not part of the ROS Lib, so it has been implemented, too. The circular buffer has been placed under the \utils\ringbuffer_class folder.

void write():

Write() method is the opposite of the read() regarding the functionality. Its only one role is place data to the used USART line. The host side (PC side) can receive this data without any additional buffering method, providing the host side implements it.

unsigned long time():

Return value of this method shall be incremented with one after each elapsed millisecond.

The following figure highlights where the Linking Layer is placed in the Simplicity Studio project structure.

Figure 2 - Linking layer location

5.2 ROS library

The ROS library has been downloaded from the ROS website, which marked as Arduino library. The necessary modules for the operation of the example application are attached for the example project. These files can be found under ros_lib/ path.

Figure 3 - ROS Lib location

5.3 Application

In this chapter, we will examine the operation of the base application (which is one of the original Arduino ROS examples), the ported application and at the end, we will compare them. The chosen application is one of the simplest Arduino related ROS_lib example which name is: blink. The expected operation of the original Arduino example is:

• build the application and upload it to an Arduino Uno
• connect the Arduino to the host computer of ROS
• enter to a terminal: roscore
• enter to another terminal: rosrun rosserial_python serial_node.py /dev/ttyUSBn
• enter to a 3rd terminal: rostopic pub toggle_led std_msgs/Empty –once

The last task can be done more times. Each repetition will cause blinking of the Arduino's LED.

The following figure compares the codes used for of Arduino and the one used for of Simplicity Studio.

Figure 4 - Comparasion of the 2 source codes

In case of SLSTK3701A, the operation will be the same as the original one, but there are differences with the setup. In steps:

• the first thing is: compile the attached project and upload the compiled *.hex file to the SLSTK
• then connect the SLSTK to the host computer, according to the following description: the ROS node initialized as to use the USART0 peripheral, which means ROS node uses the extension header related pins. The pin 4 works as Rx and the pin 6 is the Tx. I used one of the Silabs developed USART - USB converters to establish the connection between the SLSTK and the host PC, but any other appropriate device can be used.
• after the previous point the steps to take for Arduino and STK are same, so enter to a terminal: roscore
• enter to another terminal: rosrun rosserial_python serial_node.py /dev/ttyUSBn
• enter to a 3rd terminal: rostopic pub toggle_led std_msgs/Empty –once

5.4 HAL (Peripheral drivers)

It is Silabs SDK related peripheral drivers. The following figure highlights the used HAL elements for the project.

Figure 5 - HAL location

5.5 HW - EFM32GG11B_SLSTK3701A

The used development board is one of the Silicon Lab's flagship models. The ability of the EFM32GG11B is much higher than the used application requirements, but this MCU and development board is the most known board, therefore this one used for this demo project.

Problem:

When flash locking a Precision 32 device (SiM3U, SiM3C, SiM3L), J-link debug adapters, and specifically J-link commander can no longer connect to, erase, or debug the device. After attempting to connect to a device, the following response is received from J-link commander:

J-Link connection not established yet but required for command.
Connecting to J-Link via USB...O.K.
Firmware: Silicon Labs J-Link OB compiled Jan 18 2019 14:09:54
Hardware version: V1.00
S/N: 440124222
VTref = 3.259V
Target connection not established yet but required for command.
Device "CORTEX-M3" selected.

Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Scanning APs, stopping at first AHB-AP found.
AP[0] IDR: 0x24770011 (AHB-AP)
AHB-AP ROM: 0xE00FF000 (Base addr. of first ROM table)
CPUID reg: 0x00000000. Implementer code: 0x00 (???)
Unknown core, assuming Cortex-M0
Found Cortex-M0 r0p0, Little endian.

**************************
WARNING: Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M3)
**************************

FPUnit: 0 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
Cortex-M0 identified.

Solution:

The SiM3 devices require a specific series of commands, unique to these devices, to connect and erase when the parts are flash locked. The procedure is not performed automatically by J-link commander. The procedure is as follows:

SWDSelect                                 //Selects the SWD Interface
SWDWriteDP 1 0x50000000  //Enables power
SWDWriteDP 2 0x0A000000  //Selects CHIP_AP Bank 0
SWDWriteAP 0 0x00000008  //CTRL1.core_reset_ap = 1
SWDWriteAP 0 0x00000001  //CTRL1.user_erase = 1
SWDReadAP 0
SWDReadAP 0                          //Should read 1

 

A j-link commander script has been attached to this article to perform these commands. The usage is as follows:

JLink -If SWD -Speed 4000 -Device Cortex-M3 -CommanderScript <path>\SIM3_deBrick.jlink

 

 

 

 

 

This article applies to EFM32 Giant Gecko Series 1 (EFM32GG11) family.

This article references to SLSTK3701A_micriumos_httpcloader Example

SNTP Request is required when the user is trying to establish a connection between EFM32GG11 and a server using HTTPS protocol. SNTP (Simple Network Time Protocol) is a networking protocol used for clock synchronization between computers in a given network. When issuing a SNTP Request, the client attempts to connect to an NTP server indicated by the user. The NTP server responds according to the request. In the example SLSTK3701A_Micriumos_httpcloader, the SNTP Request is used to get the time elapsed from 1970 from the NTP server. If the user gets a [RTOS_ERR_TIMEOUT] error code, it is likely that the SNTP Request timed out during the communication process. This can be caused by the user’s internet server configuration. Some restricted internet servers might block public NTP server from being accessed by the local server.

Equipment Required:

1. EFM32 Giant Gecko (EFM32GG11)
2. Ethernet Cable
3. Computer with appropriate command prompt

The following command helps the user to determine if this is the cause of the timeout error

1. Ping ntpdomain (Users should replace ntpdomain with the NTP server they wish to ping) i.e., Ping 50.18.44.198 pings NTP server with the corresponding address. This tells the user if the NTP server they are trying to ping is active. This figure shows the result when the NTP server is active.

       2.If the NTP server is active, then the user can proceed to send the request to the NTP server and see if an appropriate response is generated.

1. For Windows Users:
   1. Run command: w32tm /stripchart /computer:ntpdomain /dataonly /samples:5
   2. Replace “ntpdomain” with the appropriate NTP server.
      1. This command sends 5 requests to the NTP server that the user specified.
2. For Mac Users:
   1. Run command: ntpdate -v -q ntpserver (The user should replace ntpserver with the actual NTP server address
   2. This command queries the NTP server but does not set the time.
   3. This command will return the date it has set.

If these commands return errors, then it is likely that the user’s server blocked the communication port to the NTP server.

This figure shows the error code returned by the windows command prompt. In this case, it means that either the NTP server is not running NTP server software, or UDP port 123 is blocked on the server.

The following statement is returned from a mac terminal window when the NTP server is blocked:

There are multiple ways that the user can resolve this issue.

1. The user can configure the firewall, so the port does not get blocked
2. The user can ask their server provider, i.e. IT Department for an internal NTP server if they have one
3. The user can create their own internal NTP server on a local machine that connects to the user’s current internet server

This article applies to all 32-bit Series 1 Devices except EFM32xG1. 

When the ADC is used in the Scan Mode to scan N channels, the Scan ID of the Nth channel will be 0 if - 

• REP = 1 in ADCn_SCANCTRL 
• REDELAY = NODELAY in ADCn_SCANCTRLX

There are a couple of workarounds for this issue - 

• Set REPDELAY = 4CYCLES (or more) and the Scan ID will be seen 
• If setting REPDELAY = 4CYCLES adds an extra delay in the application, the PRS can be used with the ADC as both the producer and the consumer (example attached to the article).

The attached code shows the second workaround in detail. All 32 channels are being scanned in this example. 

How can I use SDIO Initial Driver with FatFS

1. Abbreviations

• KBA - Knowledge Base Article
• SDIO Driver - SDIO Initial Driver
• SD example code - \sdks\gecko_sdk_suite\v2.4\app\mcu_example\EFM32GG_DK3750\fatcon\
• FatFS example project - output of this KBA, see the attached file

2. Configuration

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

3. What can the reader expect from this KBA

Shortly: choosing one of the available Silicon labs FatFS projects (SD example code - \sdks\gecko_sdk_suite\v2.4\app\mcu_example\EFM32GG_DK3750\fatcon) which uses SPI-driver based memory card handling. Then modify this project according to this chosen project's objectives to be able to run on a SLSTK3701A board with the SDIO Initial Driver.

This KBA will give a general description about the relation between FatFS, SDIO/SPI SD card driving and the chosen FatFS SD example code. At the end of the article the reader will get a FatFS project which will be able to run on the EFM32GG11B STK - BRD2204A with the SDIO driver instead of SPI driver. In the Silicon Labs software collection there are several FatFS example projects but all of them using SPI based SD card driving. This documentation also will describe the process of the modification, so based on this article the user can use this process to adapt the already available SPI based FatFS projects to SDIO driven FatFS project.

The structure of this KBA can be divided to 2 parts:

• the first part describes the steps with explanation, of the modifications done.
• the second part describes how can the reader use the attached project

4. Process of the modification

This chapter will describe the process how the original, SPI based FatFS example project has been modified. The steps are logically divided to 3 parts: input, which describes the available sources; output, where the summarized expected output has been described and the function, where the essential modifications are summarized in order to reach the expected outputs.

4.1. Inputs / Outputs

Firstly, we have to examine the operation of the available FatFS project (with SPI driver) and then have to plan what we should modify in order for the FatFS example to work on another board with different SD card driving peripheral (from SPI to SDIO).

The following table will classify the project related software and hardware components based on the task what these packs are doing. As synonym of the pack, I will use the word: layer. A minor description about these layers can be found in the following sections.

Table 1 - Comparison of the SPI and SDIO based projects

Figure 1 - Comparison of the SPI and SDIO based projects

4.2. Process

This chapter will give description for the previous chapter mentioned layer modification and about the modification of the layers.

4.2.1. Application

For the sake of simplicity, the introduction of the layers will start from application. The SPI driven project’s application and the SDIO driven project's application should be the same. At the end, there will be a little difference between the original application's provided functionality and the modified example project functionality because the SDIO driver has reduced capability. SDIO has been made to perform data write / read operations between the MCU and memory card, and the SPI based project has functionality which reads the memory card related size out from the memory card's register. After a deep examination, it was recognized that that the structure of the SDIO driver should be modified in order to perform this memory card size related read operation. It was decided that the driver would not be structurally modified, so the memory card size related functionality is not supported. It is not scope of this KBA.

4.2.2. FatFS

During this modification, the upper layers of the FatFS will not be modified. I do not have to examine the whole FatFS so I just separate a "logical layer" from the FatFS and I modified it. The separated layer will be called as: "FatFS – (SPI/SDIO) Card link layer". This layer related files are: diskio.c and diskio.h.

4.2.3. FatFS (SDIO/SPI) link layer

This layer is responsible for:

• standardize the low-level functionalities
• perform low level functionalities (e.g.: read/write to flash, initialize memory card, get memory card characteristics)
• working as a wrapper module

The related files were diskio.c and diskio.h. The diskio.c file has been modified. Based on the SDIO Initial Driver is not a general peripheral driver, the FatFS SD Card link layer also is not a general layer. It just works with SDHC or SDXC cards. That means that if somebody wants to use an older card (MMC or the card size smaller than 2GB it will not working). The characteristics are similar with the SDIO Initial driver's characteristics.

This layer has 4 functions which has been modified:

• disk_initialize()
• disk_status()
• disk_read()
• disk_write()
• disk_ioctl()

The disk_initialize(),disk_status(), disk_read() has been modified regarding to SDIO driver related SDIO_Init/read/write functionality. The disk_status() is just software attribute, so it was not necessary to have it modified. The disk_ioctl() functionality has been modified according to the inner functionality has been stubbed, and the return values have been modified to a constant value. This modification does not have effect to the read, write operation. The reason why this trick has been used is that the scope of this description is not an entire driver, just a working example (with reduced functionality). The concept about how somebody can implement this feature will be described at the end of this KBA (see: Issue with CMD7 chapter).

4.2.4. (SDIO/SPI) Card Driver/ (SDIO/SPI) driver

The whole SPI driver has been deleted from the project and the SDIO Driver has been replaced to its place.

4.2.5. Hardware layer / Hardware

It has been modified from EFM32GG to EFM32GG11B. Based on the standardized library, the porting has been performed without any problem.

5. Using of this FatFS example

Firstly, download the attached .zip file and extract it. The extraction will produce a Simplicity Studio project. Then, you should import the previously extracted project to your Simplicity Studio. Build the project and then upload the built *.hex file to your EFM32GG11B STK - BRD2204A Rev BD4 board. Insert a suitable (SDHC card) memory card into the board related microSD socket. Then start a terminal emulator program (PuTTy, TeraTerm, etc). For demonstrating I will use TeraTerm.

Firstly, just choose the desired port. (you can check it in the Windows related Device Manager/Ports section)

Figure - TeraTerm Choosing

Then adjust the serial connection's parameters (baud-rate: 9600; 8-N-1; no flow control)

Figure - TeraTerm Adjusting

After pressing the OK button, you should see, a blank, empty window, with one cursor. Presuming that the following steps have been performed already: the SD card is inserted and the compiled *.hex file is uploaded to MCU. You should press the reset button of the board. This reset will initiate the initialization process of the SD card, and the first message from the board should arrive.

Figure - TeraTerm Initialization complete

Then you should use the SW as described in the TeraTerm window. Note: if the "ls" command does not work firstly, you should start with "umount", "mount" then "mkdir" commands.

6. Miscellaneous

6.1. Issue with CMD7

The initialization and operation of the SD card is realized as highlighted on the above figure.

The green rectangles and arrows highlight the actual operation of the driver. The SD card initialization go through the “card identification mode”, then “stand-by state” and at the end to the “transfer state” (that what’s been implemented in the SDIO_Init function). Then the card state can go to “sending data” or “receiving data” state, after this, when the card finished its operation it will go back to “transfer state” again. That’s what exactly the SDIO Initial driver do:

• initialize HW, then go to “Transfer state” (SDIO_Init function)
• perform read/write operation (SDIO_Read/Write functions)

The red arrow marks what state change should be implemented in order to SDIO driver be able to perform read its data (size, number of blocks, etc.). This information is available when the card in “stand-by state” and that’s why SDIO_Initial driver modification is necessary to read these data.

The purpose of this project is to demonstrate how to use the Stereo MEMS Microphone on SLSTK3701A.
The MCU publishes the received data using the LCD. The received digital data are converted to decibel dimension. Each side has two textboxes where the numbers are the RMS and Peak values. Moreover, there are two scales, represent the previous values visually. The pressing of BUTTON_0 resets the Peak values.
By going through the project, the reader gets information regarding several peripherals, like I2S, TIMER, GPIO, LCD handling and interrupts.

Physical layer

The STK has two MEMS microphones, using these to capture the left- and right-side. The output signal of the microphones is PDM (Pulse Density Modulation) signal. The EFM32GG11 has no PDM processor peripheral, instead the STK has a PDM-to-I2S codec. The output from both microphones is connected to this codec which again is connected to a USART peripheral which supports I2S. The below figure shows the physical connections, see Figure 1.

Figure 1.

Physical connection.

Application workflow

As every project, it starts with the initialization of the peripherals, clocks and interrupts. Hereupon the whole application is based on a state-machine, has the following states:

1. Idle before data comes
2. Data collection in progress
3. Idle before process the data
4. Data process in progress

Have a look at for each state.
The 1st state is made for synchronization. There are two microphones, but the data arrives on one line (MIC_I2S_DATA). The I2S standard define the LRCLK signal, to indicate the codec which microphone data is needed. On low-level the left-, on high-level the right-side data will be requested from codec. The LRCLK frequency is generated automatically by USART. At the beginning peripheral and codec delay might occur, therefore it can't be sure the first USART_RX interrupt is caused by the left or right-side data. To determine the cause of the interrupt, the level of LRCLK had to be known. The PRS and GPIO Interrupt help to know the state of LRCLK. If the level is low, a GPIO interrupt occurs to sign the left data will come. The PRS is used to connect to the USART_LRCLK and the GPIO.
After the falling edge of LRCLK, the next state is coming.
The purpose of the 2nd state is to collect both side data. For this, the USART generates an interrupt, if its buffer is full. The 16 bits data are stored in a common array for both sides. After 2400 samples (1200/side), the state-machine switches to the next state.
The 3rd state is made for waiting before processing the samples. Due to the high sampling frequency(48kHz) the data gathering takes about 50 ms. The TIMER0 ensures to elapse the defined LCD update time, even if the sample rate or buffer size would be modified.
In the 4th state, the data processing follows. Here the RMS and Peak values are calculated, then a string is made from the float numbers. After all the necessary data and strings are made, the content of the LCD have to be refreshed. The "red arrow" on Figure 2. shows how the process is repeated cyclically.
After the update we must know again which side data will come, because during the processing, the data gathering has been stalled. Similarly to the 1st state, the GPIO interrupt will indicate the active side.
The below figure illustrates the above.

Figure 2.

Application workflow.

Software key points

Since the project is attached to this KBA, only the important parts of the software is highlighted.

Interrupt priority

As the whole project is based on the data via USART, important to avoid data loss. The codec transmits the bits regardless what the MCU does at that time. To be sure none of bits are lost and the frequently generated GPIO_ODD interrupt doesn't influence the USART_RX interrupt, set the priorities.

  __NVIC_SetPriority(USART3_RX_IRQn, 0);
  __NVIC_SetPriority(GPIO_ODD_IRQn, 1);
  __NVIC_SetPriority(TIMER0_IRQn, 2);

Baud rate

The data sheet of codec specifies that the BCLK has to be at least 64 times greater than the LRCLK. In addition, the typical LRCLK is 48kHz, the related BCLK is 3.072MHz. The codec has 20-bit digital output. The width of frame determines the frequency of LRCLK. For example 32[bit width frame]* 2[side]*48kHz=3.072MHz, therefore it fulfills the requirements.
The above means we should use 32bit width frames. The useful data of frame could be 16 bits, because the LSBs may mean just noise.

  def.sync.databits = usartDatabits16;
  def.sync.autoCsEnable = true;
  def.sync.baudrate = BCLK_FREQUENCY_3MHz;
  def.format = usartI2sFormatW32D16;

USART interrupt

Since 16 of 20 bits are considered, the appropriate interrupt source would be the "RX buffer is full". By using this, we do not have to deal with the other bits.
Warning: It is not enough to read the RXDOUBLE register to clear the pending RXFULL interrupt flag like in case of RXDATAV, the RXFULL interrupt flag must be cleared by software.

  USART_IntClear(USART3, USART_IFC_RXFULL);

Filter the too low values

In the USART_RX IRQ low values are ignored to get more visible change on the scales.
For instance, if the data is 1, it means ~-96dB,100 means ~-56dB. These numbers rarely come, but sometimes it happens.
By considering the size of the LCD and the possible sound pressures in a room, suitable spectrum is between -30dB and 0dB.

Test

The demo is tested with

• EFM32GG11 Giant Gecko Starter Kit (SLSTK3701A)
• Simplicty Studio V4.
• Gecko SDK Suite v2.4

 

Figure 3.

Demo on STK.

Predicament

Developer would like to append an *.s (assembly) file to ARM Cortex M based MCU project in Simplicity Studio. The compilation will be performed by GCC toolchain.

Solution

In general, Simplicity Studio projects with GCC toolchain can compile the assembly files. An example for this characteristic is the startup files which have been written in assembly code. More description about the startup file: https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/11/11/understand_the_gnua-zyam Therefore, the developer should add the assembly file to the project and the toolchain will handle it.

Steps

Step 1

Right click on the desired folder of the project -> New -> File

Give name and extension (.s) to the file, then click Finish

Step 2

Compile the project, after the compilation a new object file will appear in the compilation related folder.

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.