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.

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.