Introduction:

The goal of this article is to provide a brief introduction about the GNU assemble startup file of EFM32 and EFR32 Arm Cortex M4 devices. With this article, you can understand how the Cortex M4 processor starts.

We will take the GNU assembler startup file of EFM32GG11 startup_efm32gg11b.S as example, you can get the startup file in the folder below after installing the gecko SDK.

.\sdks\gecko_sdk_suite\v2.x\platform\Device\SiliconLabs\EFM32GG11B\Source\GCC

Bear in mind, the GNU Assembler (known as GAS) and ARM assembler are two different syntaxes for assembly language source code, however, the organization of the startup code are similar.

For more information about the GNU assembler and ARM assemble, please refer to the online documentation here.
https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_toc.html
http://www.keil.com/support/man/docs/armasm/

 

Overview of the Startup code:

The startup code consist of few parts below.

• Architecture and syntax
• Declaration of the Stack area
• Declaration of the Heap area
• Vector table
• Assembler code of Reset handler
• Definition of interrupt handler

 

Architecture and syntax

Generally, it will specify the instruction set syntax. There are two slightly different syntaxes are support for ARM and THUMB instructions, divided and unified.

    .syntax     unified
    .arch       armv7e-m

The ".arch" instruction used to select the target architecture. What the architecture of Cortex-M4 is ARMv7E-M.

 

Declaration of the Stack area

The stack is a contiguous area of memory that may be used for storage of local variables and for passing additional arguments to subroutines when there are insufficient argument registers available.

The assembly code below declares the stack area, and the ".align 3" makes the starting of this area on a multiple of 8-byte (2^3 = 8) boundary.

If didn’t define the stack size with the macro “__STACK_SIZE”, it will declare a constant Stack_Size of value 0x00000400 with the directive “.equ”.

".globl" directive makes the symbol “__StackTop” and “__StackLimit” visible to GNU linker.

Then emit Stack_Size bytes with the directive “.space Stack_Size”, it will fill the section with zero by default if didn’t specify the fill parameter for the “.space” directive.

Then set the size associated with the symbol name __StackLimit, and the size in bytes is computed from the expression “. - __StackLimit”.

    .section    .stack
    .align      3
#ifdef __STACK_SIZE
    .equ        Stack_Size, __STACK_SIZE
#else
    .equ        Stack_Size, 0x00000400
#endif
    .globl      __StackTop
    .globl      __StackLimit
__StackLimit:
    .space      Stack_Size
    .size       __StackLimit, . - __StackLimit
__StackTop:
    .size       __StackTop, . - __StackTop

The linker file will set the stack top to end of RAM, and stack limit move down by size of stack_dummy section.

  __StackTop = ORIGIN(RAM) + LENGTH(RAM);
  __StackLimit = __StackTop - SIZEOF(.stack_dummy);
  PROVIDE(__stack = __StackTop);

 

Declaration of the Heap area

The heap is a pool of memory that are managed by the processor itself (for example, with the C malloc function). It is typically used for the creation of dynamic data objects.

The assembly code below declares the heap area which are similar as the stack declaration. The labels “__HeapBase” and “__HeapLimit” indicate the starting and the ending of the heap area respectively.

    .section    .heap
    .align      3
#ifdef __HEAP_SIZE
    .equ        Heap_Size, __HEAP_SIZE
#else
    .equ        Heap_Size, 0x00000C00
#endif
    .globl      __HeapBase
    .globl      __HeapLimit
__HeapBase:
    .if Heap_Size
    .space      Heap_Size
    .endif
    .size       __HeapBase, . - __HeapBase
__HeapLimit:
    .size       __HeapLimit, . - __HeapLimit

What the __HeapBase and __HeapLimit are defined in the linker file.

 

Vector table

The vector table contains the reset value of the stack pointer, and the start addresses for all exception and interrupt handlers. Figure below shows the order of the Cortex-M4 exception and interrupt vectors in the vector table.

In general, the vector table is fixed at address 0x00000000 on system reset. The privileged software can write to the VTOR register to relocate the vector table start address to a different memory location, in the range 0x00000080 to 0x3FFFFF80.

Once an exception or interrupt is triggered, the processor automatically jumps to the corresponding address in the vector table which contains an address to the relevant exception or interrupt handlers (ISR).

For more information about each exception handler of the Cortex-M4, the reader is referred to the ARM Cortex-M4 Technical Reference Manual.

    .section    .vectors
    .align      2
    .globl      __Vectors
__Vectors:
    .long       __StackTop                 /* Top of Stack */
    .long       Reset_Handler              /* Reset Handler */
    .long       NMI_Handler                /* NMI Handler */
    .long       HardFault_Handler          /* Hard Fault Handler */
    .long       MemManage_Handler          /* MPU Fault Handler */
    .long       BusFault_Handler           /* Bus Fault Handler */
    .long       UsageFault_Handler         /* Usage Fault Handler */
    .long       Default_Handler            /* Reserved */
    .long       Default_Handler            /* Reserved */
    .long       Default_Handler            /* Reserved */
    .long       Default_Handler            /* Reserved */
    .long       SVC_Handler                /* SVCall Handler */
    .long       DebugMon_Handler           /* Debug Monitor Handler */
    .long       Default_Handler            /* Reserved */
    .long       PendSV_Handler             /* PendSV Handler */
    .long       SysTick_Handler            /* SysTick Handler */

    /* External interrupts */
    .long       EMU_IRQHandler             /* 0 - EMU */
    .long       WDOG0_IRQHandler           /* 1 - WDOG0 */
    .long       LDMA_IRQHandler            /* 2 - LDMA */
    /* ------------------- */
    .size       __Vectors, . - __Vectors

The assembly code above declared the vectors section with a multiple of 4-bytes (2^2 = 4) boundary, and then places all of the exception and interrupt handlers into the vector section with the directive “.long” since all of the handlers are 32-bit values.

As shown in the figure above, the first 32-bit of the vector table is the value for initializing the stack pointer. And the default value here is “__StackTop” that correspond to the end of RAM. So it will always initialize the stack pointer as the “__StackTop” after resetting.

At the ending, set the size of the __Vectors area, and calculate the size by subtracting the address of __Vectors from the current address.

 

Assembler code of Reset handler

After defining the vector table, we will discuss about the reset handler in the text segment.

Reset is invoked on power up or a warm reset. The exception model treats reset as a special form of exception. When reset is asserted, the operation of the processor stops, potentially at any point in an instruction.

When reset is deasserted, execution restarts from the address provided by the reset entry in the vector table, which is “Reset_Handler” in our example.

“.type” directive set the symbol “Reset_Handler” to be a function symbol.

    .text
    .thumb
    .thumb_func
    .align      2
    .globl      Reset_Handler
    .type       Reset_Handler, %function
Reset_Handler:
#ifndef __NO_SYSTEM_INIT
    ldr     r0, =SystemInit
    blx     r0
#endif

If didn’t define the macro __NO_SYSTEM_INIT, it will load the address of “SystemInit” function to R0, and then branch to the label “SystemInit” which defined in the “system_efm32gg11b.c” for system initialization (e.g. set the Vector Table Offset) before the main() routine and any data has been initialized.

After resetting the system, it will branch to the function “ _start”. In fact, the function is provided by the C standard library, in a file called crt0.o, which include a set of execution startup routines to perform initialization and then call program’s main function.

#ifndef __START
#define __START _start
#endif
    bl      __START

    .pool
    .size   Reset_Handler, . - Reset_Handler

The source code of crt0.s for ARM Cortex-M can be found on the link below with the path newlib/libc/sys/arm/crt0.S, and you can find the call to main() around line 400.

https://developer.arm.com/open-source/gnu-toolchain/gnu-rm

In fact, before branching to the main function, there are much assembler code used for copying data from read only memory to RAM, and clearing the BSS sections.

 

Definition of interrupt handler

During the code execution, there might be exception or interrupt occurs, and the processor will start executing the exception or interrupt handler.

This “.weak” directive sets the weak attribute on the symbol “Default_Handler”, if the symbol does not already exist in the source code, it will be created. And by default, the handler is just an endless loop by the directive “b .”

    .align  1
    .thumb_func
    .weak   Default_Handler
    .type   Default_Handler, %function
Default_Handler:
    b       .
    .size   Default_Handler, . - Default_Handler

And then use the commands “.macro” and “.endm” to define a macro to define the default handlers for all of the exception and interrupt except Reset.

Define a macro called “def_irq_handler” with an argument “handler_name”, the macro will set the symbol “\handler_name” as weak, and then set the value of the symbol “\handler_name” to “Default_Handler”.

    .macro  def_irq_handler	handler_name
    .weak   \handler_name
    .set    \handler_name, Default_Handler
    .endm

    def_irq_handler     NMI_Handler
    def_irq_handler     HardFault_Handler

For e.g. look at the NMI exception handler above, with the definition of the macro, “def_irq_handler     NMI_Handler” is equivalent to the assembly input below:

    .week	NVI_Handler
    .set	NVI_Handler, Default_Handler

So the default handlers of all of the exception and interrupt handlers except Reset will be set as “Default_Handler” which is an endless loop.

 

Reference:

GNU Assembler Manual
https://ftp.gnu.org/old-gnu/Manuals/gas-2.9.1/html_chapter/as_toc.html

Using ld (The GNU linker)
https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html

Cortex-M4 Device Generic User Guide
http://infocenter.arm.com/help/topic/com.arm.doc.dui0553a/DUI0553A_cortex_m4_dgug.pdf

Customer PCB (Use EFM32PG12 STK as an example):

• Modify EFM32PG12 cslib example
• Remove RETARGET_VCOM defined symbol in IDE, use RETARGET_USART0 by default (USART0 TX – PD10)
• Build, download, and run the example
• Connect GND (Pin 1) and PD10 (Pin 12) on EXP Header of EFM32PG12 STK to GND (Pin 15) and Virtual COM TX (Pin 2) on Simplicity Connector of EFM32GG11 STK

Starter Kit with Simplicity Connector to run CSP (Use EFM32GG11 STK as an example):

• Set the STK debug mode to [OUT]
• The DEBUG OUT LED next to the Debug Connector will turn on
• Run CSP on EFM32GG11 STK to monitor the capacitive sense buttons on customer PCB

Introduction

Simplicity Studio is an integrated development environment (IDE) based on Eclipse that simplifies the IoT development process. It provides hardware configuration, network analysis, real-time energy debugging, a high-powered IDE, and links to helpful resources.

Similar as Eclipse, the Simplicity Studio also supports headless build, it means that the user can run a project build from command line rather than starting the graphical user interface of Simplicity Studio. 

The goal of this article is to provide a brief introduction about how to perform the headless build, and how to use the API provided by Silicon Labs to customize the Python script to generate the automatic building script for your project.

 

Build project from Command Line

For using the headless build, make sure that you have installed the Simplicity Studio V4 and Python 2.7.x. And then obtain the Python script for headless build from the AN1121.

After that, you can launch the Simplicity Studio with command line to execute the Python script to perform the headless build now.

For example, if you have created a Simplicity Studio project, suppose the project name is "SLSTK3701A_blink" and locates at the workspace "v4_workspace_peripherals". Use the command line below to perform the headless build. It's recommended to use the full path to the workspace instead of the relative path.

\SiliconLabs\SimplicityStudio\v4\developer\scripting\runScript.bat -data \Users\yucheng\SimplicityStudio\v4_workspace_peripherals \Users\yucheng\Downloads\AN1121SW\an1121_headless_builds\PythonScripts\BuildExistingProject_v2.py SLSTK3701A_blink -cfg "GNU ARM v7.2.1 - Debug"

Note that, user can specify the build configuration with the optional argument –cfg. For example, perform the release build with the argument -cfg "GNU ARM v7.2.1 - Release". Also you can build the project with the argument –cfg “IAR ARM – Release” if it's an available build configuration for the project.

The screenshot below show the build result.

 

Customize the Script:

It provides a set of available arguments and commands that can be used to customize the Python scripts. For example, the python script“BuildExistingProject_v2.py” used above will perform the full build (clean and then build) by default, user can modify the parameter OPTION_BUILD_TYPE of the build option for different build type.

  buildOptions = { 
    # OPTION_BUILD_TYPE: BUILD_TYPE_FULL,
    # OPTION_BUILD_TYPE: BUILD_TYPE_CLEAN,
    OPTION_BUILD_TYPE: BUILD_TYPE_INCREMENTAL,
    OPTION_BUILD_CONFIG: buildConfig, 
    OPTION_NO_AUTO_ENABLE : noAutoEnable 
  }

Also, lots of API be provided to maximize the flexibility of the Python script. With the given APIs, user can get the information of the workspace, projects, project's configuration etc.

For example, if need to build all of the exist projects in the specified workspace, user can get the list of the names of the projects in the workspace with the API  "getProjectsInWorkspace()", and then get the IProject handle of each project with the API "getProject()", and then build the project with the API "buildProject()"

projList = getProjectsInWorkspace()
print "project list in workspace: " 
for projItem in projList:
  print projItem

 

Reference:

Simplicity Studio™ User's Guide:

https://www.silabs.com/documents/public/application-notes/AN0822-simplicity-studio-user-guide.pdf

Headless Builds with Simplicity Studio v4:

https://www.silabs.com/documents/public/application-notes/an1121-headless-builds.pdf

Do the RTCC retention registers have the same access time as regular RAM or do they reside in a low frequency clock domain and require multi-cycle accesses?

 

As the Clock Management Unit (CMU) chapter in the reference manual for each Series 1 EFM32 or EFR32 device shows, the Real Time Counter and Calendar (RTCC) is clocked by the LFECLK, but there's no indication if this is used for the retention registers. To figure out the actual cycle counts needed to access the retention registers, we'll need to run some code in sufficiently tight loops that performs reads or writes over which we can find a per iteration average.

 

Here's what this code looks like:

 

// emlib
#include "em_chip.h"
#include "em_cmu.h"
#include "em_emu.h"
#include "em_gpio.h"
#include "em_rtcc.h"

// BSP
#include "bsp.h"

// SDK drivers
#define RETARGET_VCOM
#include "retargetserial.h"

#include 
#include 

static void initRTCC(void);

int main(void)
{
  unsigned int msTicks_start, msTicks_end;

  unsigned int loop, retRate, ramRate;

  register volatile unsigned int word0;
  register unsigned int word1;

  // Device initialization
  CHIP_Init();

  // Set the HFCLK frequency
  CMU_HFRCOBandSet(cmuHFRCOFreq_16M0Hz);

  // Enable clock to access LF domains
  CMU_ClockEnable(cmuClock_HFLE, true);

  // Select LFRCO as LFECLK for RTCC
  CMU_ClockSelectSet(cmuClock_LFE, cmuSelect_LFRCO);
  CMU_ClockEnable(cmuClock_RTCC, true);

  // Retarget STDIO to USART1
  RETARGET_SerialInit();
  RETARGET_SerialCrLf(1);

  // Start SysTick at max value and count down
  SysTick->LOAD = 0xffffff;
  SysTick->CTRL |= (SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk);

  // Retention register write loop
  msTicks_start = SysTick->VAL;

  for (loop = 0; loop < 16384; loop++)
  {
    RTCC->RET[0].REG = loop;
    __DSB();
  }

  msTicks_end = SysTick->VAL;

  retRate = msTicks_start - msTicks_end;

  printf("Done: %u retention writes in %u ticks\n\n", 16384, retRate);

  // Retention register read loop
  msTicks_start = SysTick->VAL;

  for (loop = 0; loop < 16384; loop++)
  {
    word1 = RTCC->RET[0].REG;
    __DSB();
  }

  msTicks_end = SysTick->VAL;

  retRate = msTicks_start - msTicks_end;

  printf("Done: %u retention reads in %u ticks\n\n", 16384, retRate);

  // RAM write loop
  msTicks_start = SysTick->VAL;

  for (loop = 0; loop < 16384; loop++)
  {
    word0 = loop;
    __DSB();
  }

  msTicks_end = SysTick->VAL;

  ramRate = msTicks_start - msTicks_end;

  printf("Done: %u RAM writes in %u ticks\n\n", 16384, ramRate);

  // RAM read loop
  msTicks_start = SysTick->VAL;

  for (loop = 0; loop < 16384; loop++)
  {
    word1 = word0;
    __DSB();
  }

  msTicks_end = SysTick->VAL;

  ramRate = msTicks_start - msTicks_end;

  printf("Done: %u RAM reads in %u ticks\n\n", 16384, ramRate);

  // Wait here
  while (1);
}

 

Running this code on a Series 1 Giant Gecko device at 16 MHz, we get the following output:

 

Done: 16384 retention writes in 180505 ticks

Done: 16384 retention reads in 196930 ticks

Done: 16384 RAM writes in 114693 ticks

Done: 16384 RAM reads in 98309 ticks

 

At first glance, we can see that accesses to the retention registers are slower than RAM. Based on these numbers, each iteration of the retention write loop takes 180505 / 16384 = 11 clock cycles. Let's break this down further by looking at the disassembly:

 

  for (loop = 0; loop < 16384; loop++)
    2484:	2400      	movs	r4, #0
  {
    RTCC->RET[0].REG = loop;
    __DSB();
  }
    2486:	f8c3 4104 	str.w	r4, [r3, #260]	; 0x104
    248a:	f3bf 8f4f 	dsb	sy
    248e:	3401      	adds	r4, #1
    2490:	f5b4 4f80 	cmp.w	r4, #16384	; 0x4000
    2494:	d1f7      	bne.n	2486 

 

Of the 11 clock cycles, we know the adds and cmp.w instructions take 1 clock while the bne.n takes 2. The data synchronization barrier (dsb sy), which we insert in order to force the core to wait for completion of the memory write, takes 1 clock plus however many cycles are required for previous memory accesses to complete. Similarly, we know that the str.w takes 2 clocks plus the memory access. Putting this together, we find that the retention register access itself takes 11 - 2 (str.w) - 1 (dsb)  - 1 (adds) - 1 (cmp.w) - 2 (bne.n) = 4 clock cycles.

Now, let's compare this to this to RAM writes. Each iteration of the loop takes 114693 / 16384 = 7 clock cycles. Here's the disassembly:

 

 for (loop = 0; loop < 16384; loop++)
 {
   word0 = loop;
   __DSB();
 }
 24c6: 9401 str r4, [sp, #4]
 24c8: f3bf 8f4f dsb sy
 24cc: 3401 adds r4, #1
 24ce: f5b4 4f80 cmp.w r4, #16384 ; 0x4000
 24d2: d1f8 bne.n 24c6 

 

The resulting assembly is identical to that used for the retention register write loop with the only difference being the use of the stack pointer-relative access to RAM. It follows, then, that we can find the RAM access itself takes 7 - 2 (str) - 1 (dsb)  - 1 (adds) - 1 (cmp.w) - 2 (bne.n) = 0 clock cycles.

Wait a second! How can a RAM access take 0 clock cycles? The answer is that it can't. A closer inspection reveals that the str instruction takes 2 clock cycles. The first cycle is the decoding/dispatching of the opcode while the second is the actual memory write. So, knowing this, we can say that a zero wait state write to RAM on EFM32/EFR32 takes 1 clock cycle. This also means that the retention register write takes 5 clocks cycles, 4 more than a RAM write, which is what we actually calculated above.

Having gone through this exercise for writes, we can now examine the disassembly of the read loops for both RAM and retention registers. Here's the code for RAM:

 

 for (loop = 0; loop < 16384; loop++)
 {
   word1 = word0;
   __DSB();
 }
 24e4: 9b01 ldr r3, [sp, #4]
 24e6: f3bf 8f4f dsb sy
 24ea: 3c01 subs r4, #1
 24ec: d1fa bne.n 24e4 

 

Each iteration of this loop takes 98309 / 16384 = 6 clock cycles such that the memory access is 6 - 2 (ldr) - 1 (dsb) - 1 (subs) - 2 (bne.n) = 0 clock cycles. Of course, just like the str instruction, the ldr instruction consists of a decode/dispatch and a memory read, which we know takes 1 clock cycle for zero wait state RAM. Similarly, we can find that each retention register read takes 196930 / 16384 = 12 clock cycles. Here's the loop disassembly:

 

 for (loop = 0; loop < 16384; loop++)
 {
   word1 = RTCC->RET[0].REG;
   __DSB();
 }
 24a8: f8d3 1104 ldr.w r1, [r3, #260] ; 0x104
 24ac: f3bf 8f4f dsb sy
 24b0: 3c01 subs r4, #1
 24b2: d1f9 bne.n 24a8 

 

The cycle counts here are the same as above such that the retention register read is 12 - 2 (ldr.w) - 1 (dsb) - 1 (subs) - 2 (bne.n) = 6 clock cycles longer than a RAM read (7 clocks total). With this data in hand, let's summarize what we know so far:

 

	RAM Read	RAM Write	Retention Register Read	Retention Register Write
Clock Cycles	1	1	7	5

 

But this is just one data point: 16 MHz operation on Series 1 Giant Gecko. These figures can and do differ across operating frequency and other Series 1 devices. The table below summarizes the execution times for each loop iteration across all Series 1 devices.

 

 

Note that these are the per iteration cycle times for each read and write loop and not the actual read and write cycle access times. These must be calculated from examination of the assembly code for each loop. On the devices with the Cortex-M4 core, these are exactly what is shown above, so why are there differences? For starters, flash wait states extend the instruction fetch times and, thus, their execution times. The Memory System Controller instruction cache largely counters this as can be seen for Giant Gecko where this has little impact as the number of wait states is increased from 0 to 1 to 2.

Obviously, flash wait states alone are not the only factor affecting performance. On Giant Gecko, wait states are also introduced for peripheral accesses at frequencies above 50 MHz and for RAM at frequencies above 38 MHz. In the case of xG1 and xG13 vs. xG12, the ability of each design to meet specific timing requirements is clearly a factor. Despite having comparable core feature sets, it shouldn't be a surprise that the superset 1 MB flash/256 KB RAM xG12 devices might not be capable of supporting the same access times as their slimmer xG1 and xG13 siblings.

Finally, it's worth examining why Series 1 Tiny Gecko (EFM32TG11) requires more clock cycles to execute each loop iteration than the other devices when running at comparable frequencies, especially in the case of RAM. The differences here are specifically due to the different micro architecture of the Cortex-M0+ core. Let's first look at the disassembly of the retention register read loop:

 

 for (loop = 0; loop < 16384; loop++)
 {
   word1 = RTCC->RET[0].REG;
   __DSB();
 }
    265c:	58c8      	ldr	r0, [r1, r3]
    265e:	f3bf 8f4f 	dsb	sy
    2662:	3c01      	subs	r4, #1
    2664:	2c00      	cmp	r4, #0
    2666:	d1f9      	bne.n	265c 

 

This alone does not seem substantially different from the assembly generated by the compiler for Cortex-M4 devices. The subs and cmp instructions execute in a single cycle while the ldr is nominally a two clock operation. Where we find a difference is the dsb instruction, which takes 3 clocks on the Cortex-M0+. Factoring this in, we can now see that the retention register read takes an extra 17 - 2 (ldr) - 3 (dsb) - 1 (subs) - 1 (cmp) - 2 (bne.n) = 8 cycles on Tiny Gecko 11, thus making the entire access 9 clock cycles when running at 19 MHz and zero wait states.

Knowing this, we should expect the RAM read loop to require no extra clock cycles beyond those required for the opcodes and the RAM access itself. Here's the disassembly:

 

for (loop = 0; loop < 16384; loop++)
{
  word1 = word0;
  __DSB();
}
    269a:	9b01      	ldr	r3, [sp, #4]
    269c:	f3bf 8f4f 	dsb	sy
    26a0:	3c01      	subs	r4, #1
    26a2:	2c00      	cmp	r4, #0
    26a4:	d1f9      	bne.n	269a 

 

From the table above, we know the RAM read loop takes 10 clocks per iteration, so it's a simple matter to see that the RAM access itself takes 10 - 2 (ldr) - 3 (dsb) - 1 (subs) - 1 (cmp) - 2 (bne.n) = 1 extra cycle on Tiny Gecko 11. In other words, the ldr instruction takes 3 clock cycles: one to decode the opcode and two for the read from RAM. As also shown in the table above, each iteration of the RAM write loop takes 10 clock cycles and, given the similarity of the assembly language output from the C compiler, we can simply substitute a str instruction into the listing above and see that the same timing applies. The calculation for the retention register write loop is left as an exercise for the reader.

Our application makes use of energy harvesting, so we try to overlap operations in our firmware when possible, e.g. using the LDMA to service a peripheral while the CPU is executing code. So, knowing this, can you tell us if it is possible to run code from the boot loader flash on EFM32TG11 at the same time as we are programming the main flash array?

 

What a great question! This seems like a reasonable assumption because the boot loader flash array on Series 1 devices resides at address 0x0FE10000 while the main flash array sits at 0x0. Given the two different base addresses, these would seem to be physically distinct flash arrays that would have their own dedicated charge pumps for generation of the high voltages used during program and erase operations.

 

Alas, in this case, different addresses do not mean physically separate arrays with separate charge pumps. Running code that programs or erases the flash from the boot loader array is subject to the same CPU stall that occurs when from the main flash array on devices that have single flash instances (more on this later). Let's investigate this further. Is there a visually satisfying way that shows us what's actually happening with the CPU when the flash high voltage is applied? Of course there is! We can toggle a GPIO pin.

 

First, though, we need to consider how to actually get code into the boot loader space. To do that, we'll follow the steps outlined in the Knowledge Base article "Using a Linker Script in GCC to Locate Functions at Specific Memory Regions" and have Simplicity Studio use a custom linker file with some additions. To start, we'll add the BLFLASH region of memory. Note that the first 4 KB of the boot loader flash is excluded specifically to keep the EFM32TG11 factory boot loader intact.

 

MEMORY
{
	FLASH (rx) : ORIGIN = 0x0, LENGTH = 0x20000 /* 128k */
	BLFLASH (rx) : ORIGIN = 0x0FE11000, LENGTH = 0x4800 /* 14k */
	RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x8000 /* 32k */
}

 

The .blspace section is added next for functions designated to reside in the BLFLASH region of memory:

 

  .blspace :
  {
    . = ALIGN(4);
    __blspace_start__ = .;
	*(.blspace*)
    __blspace_end__ = .;
  } > BLFLASH

 

Lastly, a check is added to make sure functions placed in the .blspace section do not overflow the allotted space:

 

  /* Check if BLFLASH usage exceeds FLASH size */
  ASSERT( LENGTH(BLFLASH) >= (__blspace_end__ - __blspace_start__), "BLFLASH memory overflowed!")

 

We'll use the following simple program to directly issue a flash page erase (no use of emlib in order to keep the code compact and as close to assembly as possible). Notice the commented out function declarations. We'll make use of these later to place the erasepage() function in main flash or RAM in order to see how it behaves.

 

#include "em_device.h"

void erasepage(void);

int main(void)
{
  // Disable MSC prefetch
  MSC->READCTRL  &= ~_MSC_READCTRL_PREFETCH_MASK;

  // Disable the MSC cache
  MSC->READCTRL |= MSC_READCTRL_IFCDIS;

  // Configure PC2 as an output
  CMU->HFBUSCLKEN0 |= CMU_HFBUSCLKEN0_GPIO;

  GPIO->P[2].MODEL = GPIO_P_MODEL_MODE2_PUSHPULL;

  while (1)
  {
    erasepage();
  }
}

#define BLSPACE  __attribute__((__section__(".blspace")))

void BLSPACE erasepage(void)
//void __attribute__ ((section(".ram"))) erasepage(void)
//void erasepage(void)
{
  // Enable writes
  MSC->WRITECTRL |= MSC_WRITECTRL_WREN;

  // Address to erase
  MSC->ADDRB = 0x8000;

  // Load internal write address register from MSC_ADDRB
  MSC->WRITECMD = MSC_WRITECMD_LADDRIM;

  // Turn on PC2
  GPIO->P[2].DOUT = 0x4;

  // Enable high voltage to start erase operation
  MSC->WRITECMD = MSC_WRITECMD_ERASEPAGE;

  // Flush pipeline after starting erase
  __NOP();
  __ISB();

  // Turn off PC2
  GPIO->P[2].DOUT = 0x0;

  // Make sure erase is complete
  while (MSC->STATUS & MSC_STATUS_BUSY);

  // Halt here
  __BKPT(0);
}

 

So, with the code downloaded to the Tiny Gecko 11 device and the erasepage() function residing at 0x0FE11000 in the boot loader flash, here's what we see on the scope:

 

 

That 26.3 ms pulse is nicely in line with the typical page erase time specified in the datasheet, too:

 

 

Naturally, we should see what happens when the erasepage() function is placed in the main array. To do so, we can remove the BLSPACE attribute from the erasepage() function declaration or simply comment out the declaration entirely and uncomment the third declaration which excludes the BLSPACE attribute. Here's what we see now:

 

 

Looks good! This matches right up with the result seen when running from the boot loader array, which indicates that, in both cases, the CPU is stalled while the high voltage is applied to the flash during the erase operation. Of course, we need to see the alternative, which is what happens when erasepage() runs from RAM. To see, this comment out the current declaration that places the code in flash and uncomment out the declaration with the .ram section attribute. Running this code, we see:

 

 

The short duration of this GPIO pulse when running erasepage() from RAM clearly indicates that the CPU is still executing code while the high voltage is applied. Series 1 devices default to operation at 19 MHz, so this amounts to just a few instructions as shown below in the debugger disassembly:

 

 

Knowing all of this, there is a remaining question: What happens on dual bank devices like EFM32PG12, which explicitly have read-while-write (RWW) support via the MSC_WRITECTRL_RWWEN bit. Let's run the same code with erasepage() in the boot loader flash but with the erase target addresses being 0x40000 and 0xC0000, which, on Pearl Gecko 12, are in the bottom and top flash banks, respectively. We'll also need to modify the write enabling sequence to permit RWW operation as follows:

 

  // Enable writes
  MSC->WRITECTRL |= (MSC_WRITECTRL_WREN | MSC_WRITECTRL_RWWEN);

 

In the side-by-side scope captures below, the page erase operation takes the datasheet typical 27 ms when the target address is 0x40000 but only 1.8 µs when the target address is 0xC0000. What this shows is that the boot loader flash is part of the same physical flash block as the bottom flash bank (0x0 to 0x7FFFF) and thus shares the same high voltage circuitry. The top flash bank (0x80000 to 0xFFFFF) is physically distinct from the boot loader array, which is why code can continue executing even when the high voltage is applied for erasing (or programming).

 

 

Users of Giant Gecko Series 1 should take note that this behavior is reversed. On these devices, the boot loader array is associated with the upper flash bank, so RWW is possible when the target of flash operations is in the lower flash bank. Of course, as the reference manual denotes, RWW is always possible when code is running in one of the physical flash arrays and the target of flash operations is the other (e.g. lower bank and upper bank or vice versa).

We're using Flex Gecko and want to know if there is a way in software to detect if a debugger is connected? There are times when we might want our software to behavior differently or provide access to certain functions if we know the system is operating under debug control.

 

This is a question that many EFM32, EFR32, and EZR32 customers might have. It's also one that ARM would seem to have addressed given how device operation is governed by debug status.

 

The Debug Halting Control and Status Register (DHCSR) at 0xE000EDF0 in core space provides fundamental control of basic CPU operation, e.g. halting and stepping the core. Bit 0 of this register is the C_DEBUGEN bit, which, as it's name implies, is the control bit that enables debug.

 

 

Some users might see this and immediately think that it's possible to enable debug mode, or, better still, force debugger disconnection, under software control. Alas, this is not the case because, as ARM's documentation makes clear, C_DEBUGEN "can only be written by (the) AHB-AP and not by the core. It is ignored when written by the core, which cannot set or clear it."

 

What is the AHB-AP? The AMBA High-Performance Bus - Access Port is the name for what ARM calls a memory access port, a block intended for use by the Cortex M-series software debug (SWD) interface to read and write memory and registers present on the AHB.

 

Even though the CPU cannot write C_DEBUGEN, it is able to read it. This effectively makes it a status bit, thus providing a means for software to modify its behavior when under debugger control.

A potential issue can arise with the initialization and use of ACMP0 on a Series 1 EFR32 device in which the input channels can be configured (using the emlib function ACMP_ChannelSet()), but then the device does not respond as expected to comparator input after the ACMP is initialized using ACMP_Init(). 

This problem may be the result an order of operations issue where input pin settings get changed when you call ACMP_Init().  Comparator negative and positive inputs can be configured using the function ACMP_ChannelSet(), which configures the ACMP0_INPUTSEL register.  This function should be called after calling ACMP_Init(), however, as the function ACMP_Init() appears to overwrite the INPUTSEL register at line ~417:
 

  acmp->INPUTSEL = (0)

Configuring the inputs after calling ACMP_Init() should eliminate this behavior.

Additionally, please refer to the attached example project (acmp.zip) for a working ACMP0 example you can run on an EFR32MG12 WSTK (easily ported to other Series 1 EFx32 devices), which shows interrupt usage as well as GPIO output from the ACMP0.  Please import this project into Simplicity Studio using [Project]>[Import...]>[MCU Project] and then pointing it to the .slsproj file for the MG in the directory where you have unzipped the project.  Your imported project should use the source file "main_PGMG.c."

Problem:

I used the JLink Commander to erase my EFM32GG11 device, and now the device does not seem to run code and appears bricked.

Solution:

The issue of code failing to run on the EFM32GG11 device after erasing the device using J-Link Commander is both expected and easily fixable.  On the EFM32GG11, unlike in the series 0 EFM32 devices, the device stores its bootloader in a dedicated memory region at location 0x0FE10000.  Depending on the state of bit 1 of the CLW0 word in the lock bits (LB) page (word 122 of the LB page), following reset the device will either start program execution at the bootloader area (0x0FE10000) or at 0x00000000.  If CLW0[1] = 1 (default), the device begins execution from 0x0FE10000, and if CLW0[1] = 0, then the bootloader is bypassed and the device executes at 0x00000000.

For some time, EFM32GG11 devices were shipped with a bootloader stub at the bootloader location which simply loaded the initial stack pointer and branched to 0x00000000.  Later, and as is the default now, EFM32GG11 device ship with the AN0003 UART bootloader loaded in the bootloader space.  You can download the AN0003 text and firmware here:

https://www.silabs.com/documents/public/application-notes/an0003-efm32-uart-bootloader.pdf
https://www.silabs.com/documents/public/example-code/an0003-efm32-uart-bootloader.zip

It appears that the JLink commander "erase" command erases the user space as well as the bootloader space of the device.  Thus, when the part subsequently comes out out of reset, program execution begins at 0x0FE1000, which contains no usable code, and the device runs off into the weeds.  There are several options to remedy this situation:

1) Program the AN0003 bootloader hex image to the device.  Download the AN0003 software package from the link above and program the binary file "bl-usart-geckoG1-v2.07.hex" from the \an0003_efm32_uart_bootloader\binaries folder to the device.

2) Program the bootloader stub that I have attached to this post to the device.

3) Clear CLW0[1] in the LB page to bypass/disable the bootloader.  For some information on how to do this, please refer to the following knowledge base articles, which discuss slightly different but analogous modification of the LB page:

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/06/07/erasing_the_lockbit-WVQL
https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/10/09/how_to_lock_or_disab-mb2d

Also, for more information, please refer to section 6.3, table 6.1, section 6.3.2 and 6.3.4 on pages 168-170 of the EFM32GG11 reference manual.

Question: 

What signals can be used to drive the CLKIN0 input on Series 1 MCUs (EFR32/EFM32) devices on which it appears?

 

Answer:

Some EFR32 and EFM32 Series 1 MCU devices support a CLKIN0 input to the CMU module, as depicted below - taken from Figure 10.1 "CMU Overview - High Frequency Portion" of the EFM32PG12 Reference Manual:

The purpose of the CLKIN0 input path is two-fold, depending on what is implemented on a particular MCU device.  CLKIN0 supports a low-frequency (<= 1 MHz) square wave clock input which can be used:

1. to clock the device from an external CMOS source (BLUE path above), or
2. by the DPLL as a reference clock (GREEN path above)

For guidance on how to implement either of these configurations, see the following Knowledge Base articles:

• "CLKIN0 on MCU Series 1"
• "DPLL on MCU Series 1"

In Asynchronous mode, the USART (or UART) can be configured to oversample the incoming UART transmissions. By default, Majority Vote is enabled, which provides some level of noise immunity by sampling each bit three times at the middle of the bit period. The value of the sampled bit is determined by majority vote - if two of the three samples are high, the bit will be recorded as high. 

A figure showing how majority voting samples the bit period is shown below.

For OVS = 0 (16x oversampling), these samples are taken at positions 8, 9, and 10. For OVS = 1 (8x oversampling), samples are taken at 4, 5, and 6. For OVS = 2 (6x oversampling), samples are taken at 3, 4, and 5. For OVS=3 (4x oversampling), majority voting is not used.

Majority vote can be disabled by setting MVDIS in USARTn_CTRL. In this case, if oversampling is enabled, only one sample will be taken. This will be sample 9 above for 16x, 5 for 8x, and 4 for 6x.