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

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)

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

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.

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.

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.