Question

How do I use the alternate excite pin for LESENSE excitation in series 1 devices?

Answer

There are a total of 16 channels in the LESENSE peripheral, and there are 8 alternate excitation pins. Each alternate excite pin is mapped to Channel X and Channel X + 8 with 0 < X < 8. For pin mapping of each device, please refer to the Alternate Functionality Overview section in the device's datasheet.

In order to use the alternate excitation pin, add the following sequence into the LESENSE initialization routine:

1. Set ALTEX to true in the LESENSE_CHx_INTERACT register (x being the channel number you want to configure).

2. Set ALTEXMAP to ALTEX in the LESENSE_CTRL register.

3. Enable the corresponding channel pin (CHxPEN) and Altex pin (ALTEXxPEN) in LESENSE_ROUTEPEN register.

4. Configure the LESENSE_ALTCONFIG register for desired setting (check register description in the reference manual for more information).

5. Make sure the corresponding GPIO pin for alternate excite is set to push-pull output if the excitation type is logical low or logical high.

You should be able to see the excitation pulse in the alternate excite pins with these configuration added.

An example of using LESENSE excitation pin is attached in this article. The example runs on an EFR32MG12 starter kit and the excitation pulse is on PA8, which is the alternate excitation pin for LESENSE channel 0 on EFR32MG12. The code added to enable alternate excite is:

  LESENSE -> CTRL |= LESENSE_CTRL_ALTEXMAP_ALTEX;
  LESENSE -> ROUTEPEN |= LESENSE_ROUTEPEN_ALTEX0PEN | LESENSE_ROUTEPEN_CH0PEN;
  LESENSE -> CH[0].INTERACT |= LESENSE_CH_INTERACT_ALTEX;
  LESENSE -> ALTEXCONF |= LESENSE_ALTEXCONF_IDLECONF0_LOW;

Introduction

EFR32 devices allow the JTAG TDI/TDO pins to be used for other functions when not needed for JTAG debugging. Under certain circumstances, such as an unexpected reset during debug, control of these pins can unexpectedly be transferred to the debug peripheral. On Series 2 devices this happens more frequently due to changes in the reset topology. In such cases, the device must be reset again to regain normal control over the pins.

Background

JTAG and SWD

EFR32 supports debugging through either the JTAG or the SWD protocol. The JTAG protocol is an industrial standard for testing and verifying PCBs that utilizes 4 pins; TCK, TMS, TDI and TDO. SWD is an ARM proprietary protocol that is interoperable with a JTAG test environment, but utilizing only two pins, the TCK and TMS pins.

Debug Port

The Serial Wire/JTAG Debug Port (SWJ-DP) is responsible for implementing both the JTAG and the SWD interface. The SWJ-DP also facilitates for switching between the two protocols on demand.

The SWJ-DP allows a designer to allocate the JTAG TDI and TDO pins to other functionality, such as GPIO, when only using the SWD interface. 

On startup the SWJ-DP will, for compatibility reasons, default to JTAG mode. In order to switch to SWD mode, a debugger will have to transmit a specific initialization sequence on the TCK and TMS pins. This initialization sequence is designed such that it will not affect any JTAG devices on the same bus.

JTAG-on-demand

JTAG-on-demand is an EFR32-specific feature that allows an EFR32 device to appear as defaulting to SWD mode. This means that the TDI and TDO pins are allocated as normal GPIO at startup instead of being allocated to the debug interface.

JTAG-on-demand will reallocate the TDI and TDO pin to the debug interface when the SWJ-DP is in JTAG mode and detects JTAG traffic. Once JTAG-on-demand has been activated, it will not be deactivated until the next full reset of the chip (and debug interface).

JTAG-on-demand can be overridden by writing to the GPIO.DBGROUTEPEN register. Attempting to write the relevant bits while the debug circuitry is active will cause a BusFault on Series 2 devices.

Series 2 reset topology

EFR32 Series 2 devices have a different reset topology than EFR32 Series 1 devices. The most notable change is that in Series 2 devices the debug interface is reset on assertion of the RESETn pin.

Error Conditions

If anything except the full SWD initialization sequence is received by the EFR32 on the debug interface while the SWJ-DP is in JTAG-mode, JTAG-on-demand will activate and transfer control of the TDI and TDO pins to the SWJ-DP.

When control of the pins has been transferred, the pins cannot be used in any other function, including normal GPIO, SWO or ETM Trace.

There are two scenarios in which loss of control over TDI and TDO is likely to occur:

• If the EFR32 is reset in a way that causes the debug interface to be reset while there is an active SWD debug session. For Series 2 device, this includes reset via the RESETn pin. The debug adapter will be unable to detect this reset in all circumstances, causing the debug adapter to continue communicating over SWD, activating the JTAG-on-demand feature.
• If the debug adapter attempts to initialize the SWD connection before the EFR32 has fully exited reset so that the SWD initialization sequence is not registered. This causes JTAG-on-demand to activate when verifying the connection as required by ARM.

While it is possible for this to occur on EFR32 Series 1 devices, it is a lot easier to trigger on Series 2 devices due to the change in reset topology. It is also not possible to override the JTAG-on-demand feature on Series 2 devices, contrary to Series 1 devices where this is possible.

Consequences

When JTAG-on-demand is activated on an EFR32 Series 2 device, the following will happen

• SWO will stop working
• ETM Trace will stop working
• Loss of control over GPIO pins PA3/PA4

For Silicon Labs development kits, the following are features that can be affected depending on what is connected to PA3/PA4:

• VUART
• Simplicity Studio Code Correlation
• External SPI Flash
• VCOM Flow Control (CTS always high)
• Button stuck high

Workaround

Once the condition occurs, the only known workaround is to disconnect all active debug sessions, reset the target through the RESETn pin or toggling power.

Glossary

Question

How to print messages to Virtual COM port by using printf() function in an MCU application?

Answer

We provide so called RETARGET functions with the aim of avoiding the needs of the low level UART peripheral configuration. The following step-by-step guide shows how to add all the necessary files and functions to a project from the scratch.

1. Create an empty MCU project

File -> New -> Project...

Figure 1.
Create an empty MCU project.

2. Copy (or link) the following emlib and RETARGET files

emlib from "<StudioPath>\v4\developer\sdks\gecko_sdk_suite\v2.7\platform\emlib\src":

• em_cmu.c
• em_core.c
• em_gpio.c
• em_usart.c

RETARGET from "<StudioPath>\v4\developer\sdks\gecko_sdk_suite\v2.7\hardware\kit\common\drivers":

• retargetio.c
• retargetserial.c

Figure 2.
Files in the project.

Note: The header files are added to the Include path by default, therefore no need to add them manually.

3. Place the RETARGET functions

The Starter Kits have a bidirectional analog switch between the MCU and the Board Controller.
The VCOM_ENABLE pin should be in high logical state for allowing the data flow through to the board controller.
Find the given pin in the User's Guide of the kit.

Figure 3.
Virtual COM Port Interface.

To realize this setting, add the below lines prior to call the RETARGET functions.
Additional headers added:

    #include "em_cmu.h"
    #include "em_gpio.h"
    #include "retargetserial.h"
    #include "stdio.h"

and place the following code after the CHIP_Init()

  //Enable GPIO clk prior to write its registers  
  CMU_ClockEnable(cmuClock_GPIO,true);

  //Enable the switch with VCOM_ENABLE pin, see User's Guide of the board
  GPIO_PinModeSet(gpioPortA,5,gpioModePushPull,1);

  RETARGET_SerialInit();
  RETARGET_SerialCrLf(1);

  printf("VCOM is working!\n");

4. Start a terminal emulator

Used serial port can be determined by Device Manager:

Figure 4.
Device Manager.

5. Build and download the image

Figure 5.
Terminal on Host PC.

IAR makes it relatively easy to locate an initialized variable in flash. One use-case of this might be to set the Debug Lock Word (DLW) in the lock bits page to lock debug access to the device.

To locate a variable in IAR, you can use the @ sign.

uint32_t myVar @ 0x2000000;

Only 'const' variables can be located and initialized however:

uint32_t const myVar @ 0x00001000 = 0x0000AABB;

Finally, in order to keep variables that will otherwise be unused, they must be declared as '__root'. So, to clear the debug lock word purely with a global variable statement:

__root uint32_t const DLW @ (LOCKBITS_BASE + (127*4)) = 0xFFFFFFF0;

Make sure that, after flashing the device, the device is reset appropriately to engage the debug lock.

To clear the debug lock word from executing code, see the following example: https://github.com/SiliconLabs/peripheral_examples/tree/master/series1/msc/debug_lock

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

Hardware Design

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

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

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

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

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

Software Design

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

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

Current Consumption

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

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

Tamper Detection

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

Debugging

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

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

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

Conclusion

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

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

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

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

For bare-metal applications:

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

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

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

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

  return (caddr_t) prev_heap_end;
}

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

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

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

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

  return (caddr_t) prev_heap_end;
}

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

For RTOS applications:

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

1. Abbreviations

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

2. Configuration

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

3. Preface

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

4. What can the reader expect from this KBA

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

5. ROS serial node

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

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.