The BRD4001A board's key dimensions  are shown in the flowing picture:

   As you can see, it shows the board size, 3 fixture holes' size and positions. For more detailed dimension, you can refer to its GERB file in the PCB design package.

 

How to setup a RAIL test example project to cope with custom hardware

 

It is a usual requirement from customers to modify an application provided by the SDK to work on the customers own hardware. RAIL test is a suitable choice for this purpose as in many cases the customers want to test their board’s performance.

Let’s assume that a minimal hardware is required, only UART is necessary all other peripheral can be disabled. By default, UART is configured to PA0/PA1 – for this example it will be relocated to PB13/PB14.

Note: in the SDK examples SPI flash is configured to use PC6/PC7/PC8/PA4 and it is hardwired to hal-efr32/hal-efr.c. So, to be able to use these I/Os as UART boardLowPowerInit() must be commented out (line 112 of hal-efr32/hal-efr.c).

It is a good approach to select a radio board which is close to the custom design from hardware point of view. Starting from custom settings (not selecting any board) will most probably result in a project where compilation errors will happen as the project relies on peripherals which are not configured.

 

As an example, if the custom design was based on EFR32FG13P233F512GM48, choose BRD4255A:

Most important chip parameters from chip selection point of view (in the following order):

• Chip family (xG1, xG12, xG13, etc.) – different radio access, different family chips are not binary compatible
• Radio option (subGHz, 2.4GHz, dual) – using unavailable radio option will result in exception
• Product line (performance, basic, value) – different maximum TX power
• Pin count – configurator does not enable setting up unavailable pins, higher pin count always works but care must be taken to not to use pins which are not wired out

This makes the configuration easier as peripherals like clock, etc. are preconfigured – obviously later on care should be taken to match the settings with the custom board. If this step is skipped and only the chip is selected, external clock will not be enabled for example so it is necessary to setup manually (although the project will compile but radio will not work).

Open the RAIL test sample application and go through the wizard:

 

Appbuilder opens immediately after project creation is finished. On General tab select Edit Architecture:

Then remove board and change the device if necessary:

 

 

A popup window will appear about hardware configuration changes:

Select Merge to update the hardware configuration.

In AppBuilder click on Plugins tab and select Application Graphics item:

 

Set USART port to None and disable SPI display:

 

Finally, uncheck Application Graphics:

 

Select HAL Library from the plugin items:

 

Uncheck unnecessary peripherals:

• BUTTON (WSTK buttons)
• LED (WSTK LEDs)
• VCOM (enable / disable virtual COM port on WSTK)
• USART1 (SPI for LCD display)

 

Set up CLI UART pins:

When finished AppBuilder configuration save it. A new custom_ prefixed .hwconf file will be created:

Click on  to generate configuration files.

Open Hardware Configurator (ex.: double clicking on .hwconf file) and select DefaultMode Peripherals. Disable PTI:

Saving hardware configuration will generate the hal-config.h file.

 

It is necessary to add "${StudioSdkPath}/hardware/kit/common/drivers" to the include paths, anyway the compiler will complain about missing retargetserial.h file:

 

At this point the project is configured for the custom board hardware. Compile and debug the firmware as usual.

 

Customizing Connect application is very similar to RAIL applications. The difference is that while RAIL enables to configure peripherals through plugin properties, Connect plugins do not have this feature, thus all hardware configuration must be done through Hardware Configurator.

 

The example application Sensor uses an I2C sensor (Si7021) and there is a plugin for this sensor called WSTK-sensors which must be disabled if the custom hardware does not have Si7021 based sensor device:

This tutorial builds on basic RAIL knowledge and does not detail all its APIs in depth. For a better understanding, please go through the RAIL tutorials if you haven't already.

Introduction

This project combines the MCU-based examples with the RAIL examples using one, or preferably two wireless starter kits. The purpose of this tutorial is to show how to include various peripheral drivers into a RAIL example project. It utilizes the basic capabilities of the RAIL while taking advantage of the built-in peripherals on the WSTKs as well, such as the LCD screen (through SPI), the digital temperature and relative humidity sensor (via I2C) and basic GPIO features, such as flashing LEDs and using interrupts for the buttons.

Specification

The specification of our application is relatively simple:

• Make the application reusable, run the same code on all WSTKs.
• The user should be able to switch between transmit and receive mode with a push of a button.
• Receive mode should be default. In this mode, receive the packet and update the screen based on the packet’s contents.
• If transmit mode is selected, read data from the thermometer and send it out in a packet.

First steps and hardware configuration

Setting up the radio configuration and the RAIL from scratch is not recommended, as it is time consuming and by using an example project we can make sure to get everything right for the first try. Let’s start our project with a RAIL example project instead. For our case the “RAIL: Simple TRX” example seems ideal: transmit and receive already work in this project all we should do is to add the graphics and sensor functionality and include the sensor data in the packet.

AppBuilder setup

After creating the project, the App Builder opens. First thing we should do is to choose a radio profile. Custom profiles can also be configured; however, a base profile is a sure bet. In this example we’re using a Mighty Gecko 868 MHz board, therefore one of the 868 MHz profiles are chosen. Choose any of the base profiles supported by your board.

  

The last step before generating the code is to disable some of the macros turned on by default in this example. Make sure the only macro enabled on the “Other” tab is the “HAL_MICRO” as we won’t need the VCOM retarget or any other debug functions in this project.

    

Press “Generate” to create the basic TRX application using RAIL.

Configuring DefaultMode Peripherals

This project is now set up to be used for RAIL, however the LCD and sensor drivers are not included yet. First, we will have to enable these peripherals ­– and disable anything unnecessary for the project – in the Hardware Configurator.

Make sure to enable the following:

• I2C Sensor (also enables I2C0)
• SPI Display (also enables USART1)

We won’t need:

• Serial
• Virtual COM port
• USART0 (can only be disabled after the first two)

Also delete the retargetserial.c file from the hal-efr32 folder as we won’t need this source anymore since we don't want to retarget the serial port in this example.

    

Including necessary drivers

To use the two extra drivers, we will need to also include them and a few other dependencies to our project's include paths.

     

Add the following lines to the include paths:

• "${StudioSdkPath}/platform/middleware/glib/dmd"
• "${StudioSdkPath}/platform/middleware/glib/glib"

And copy the following folders/files to your project.

From ${StudioSdkPath}\hardware\kit\common\drivers

To [project folder]\spidisplay\

• display.c
• displayls013b7dh03.c
• displaypalemlib.c
• retargettextdisplay.c
• textdisplay.c

To [project folder]\sensor\

• si7013.c

From ${StudioSdkPath}\hardware\kit\[your kit's folder]\config

To [project folder]\hal-config\

• retargettextdisplayconfig.h
• textdisplayconfig.h

If you did everything right, the project source tree should look something like this:

     

At this point the code won’t compile however, as some macros still need to be enabled. Add TEXTDISPLAY_FONT_8x8=1 and INCLUDE_TEXTDISPLAY_SUPPORT=1 to your Symbols under the Project properties. These two defines will let our project know that we have a screen in our design which supports text display, and we need the font size to be 8x8 pixel big.

     

Also, there’re two macros still undefined (as they are not defined for this board in the retargettextdisplayconfig.h). Modify your copy of this header file, so it’s base content will look like below. If your retargeted text display configuration file has these lines, you're good to go.

/* Display number to retarget stdout to. */
#define RETARGETTEXTDISPLAY_DISPLAY_NO   (0)

// ADDED MANUALLY
#define RETARGETTEXTDISPLAY_SCROLL_MODE (0)
#define RETARGETTEXTDISPLAY_LINE_FEED_MODE (0)

With this modification the project should compile and you should have all the necessary drivers included in it. There’s only one setting left to change and we can start writing the main functionality. We will use printf to write lines of data to the LCD which data will also contain floating point numbers (temperature, humidity). To be able to do that, make sure “Printf float” is enabled under the General Linker settings.

    

Driver initialization

RAIL and radio setup

As our initial design is already set up for transmit and receive, all the necessary RAIL configuration is done. However, as it is recommended in the RAIL tutorial: Calibrations, in this example the calibrations are also enabled. The other modification to the RAIL setup is handling the RAIL_EVENT_TX_COMPLETION event. This event combines all transmit related events – even the errors –, therefore this way we have a better opportunity to handle them. In the example code provided, all RAIL and radio related calls are grouped together into the radioInit() function provided by the original RAIL TRX example.

Initializing the LCD

With the drivers set up, we can retarget the printf function to the screen on the starter kit. This way we have an easy and convenient way to write lines of text on the screen, without having an in-depth knowledge of the graphics drivers. To initialize and retarget the screen, we need the following few lines:

// Initialize the display module
DISPLAY_Init();
// Retarget stdio to a text display
if (RETARGET_TextDisplayInit() != TEXTDISPLAY_EMSTATUS_OK) {
    while (1)
        ;
}

You can find out more of the graphical driver and using the LCD screen in the emlcd and textdisplay MCU examples for the EFM32PG kit.

Setting up the sensor

The sensor uses I²C to send the measured data. To use the sensor, we will need to initialize the I²C peripheral and enable the sensor itself through its enable pin. The I²C driver has a predefined structure for use with the sensor and the configuration files of our board should contain all the necessary locations for the data and enable pins. Do the following to setup the sensor:

// i2c init
I2CSPM_Init_TypeDef i2cInit = I2CSPM_INIT_SENSOR;
I2CSPM_Init(&i2cInit);
// Enable Si7021 sensor isolation switch
GPIO_PinModeSet(BSP_I2CSENSOR_ENABLE_PORT, BSP_I2CSENSOR_ENABLE_PIN, gpioModePushPull, 1);

Please refer to the humitemp and inttemp MCU examples for the EFM32PG kit to learn more about using the sensor. 

GPIO Callback for the buttons

The callback is already written in the Simple TRX example, the only thing we will have to do is to modify it a little. The functionality we should have is to toggle the RX and TX whenever a button is pressed.

RAIL Callback

As it was discussed in the RAIL tutorials, the way of using the RAIL is through the event handler. We can configure all kind of events and catch them in the main callback function of the RAIL. The calibration event was enabled earlier, the callback function should be modified accordingly as well. It’s not the only thing we need to modify here however. Since the simple TRX example doesn’t need the packet it receives, as default it just drops it. We would like to keep the packet and hold it for future use by calling RAIL_HoldRxPacket() after RX completion. We also would like to write a confirmation message on the screen if the packet was sent successfully and set a packet pending flag false after – any kind of – transmit completion. This flag will be necessary to monitor the scheduled (delayed) transmit and its completion.

void RAILCb_Generic(RAIL_Handle_t railHandle, RAIL_Events_t events) {
    (void) railHandle;
    if (events & RAIL_EVENT_CAL_NEEDED) {
        // Calibrate if necessary
        RAIL_Calibrate(railHandle, NULL, RAIL_CAL_ALL_PENDING);
    }
    if (events & RAIL_EVENTS_RX_COMPLETION) {
        // Toggle RX LED and hold the packet if something was received
        BSP_LedToggle(LED_RX);
        packetRx = true;
        if ((events & RAIL_EVENT_RX_PACKET_RECEIVED)
                && packetHandle == RAIL_RX_PACKET_HANDLE_INVALID) {
            packetHandle = RAIL_HoldRxPacket(railHandle);
        }
    }
    if (events & RAIL_EVENT_TX_PACKET_SENT) {
        // Toggle TX LED and print sent message on successful packet sent event
        BSP_LedToggle(LED_TX);
    }
    if (events & RAIL_EVENTS_TX_COMPLETION) {
        // Clear the pending flag if TX is complete (even if it was a failure)
        txPacketPending = false;
    }
}

Handling transmit and receive in the main loop

Inits are done, Callbacks were written, it’s time to create the main functionality of the example!

Processing the received packet

In the main endless loop, the first thing we should do is to check if any packet was received. The easiest way to do that is to check the RAIL_RX_PACKET_HANDLE_INVALID flag. If it’s valid, there’s a packet in the FIFO. All we should do is to copy this packet, process its contents and write them on the screen. After this, we should release the packet making space for the next one.

// If anything was received, process the data and push it to the screen
if (packetHandle != RAIL_RX_PACKET_HANDLE_INVALID) {
    RAIL_RxPacketInfo_t packetInfo;
    RAIL_GetRxPacketInfo(railHandle, packetHandle, &packetInfo);
    RAIL_CopyRxPacket(receiveUnion.raw, &packetInfo);
    // Copy the held packet using its packet info
    RAIL_ReleaseRxPacket(railHandle, packetHandle);
    // Release the packet once it was copied
    packetHandle = RAIL_RX_PACKET_HANDLE_INVALID;
    printf("\f\n\n\n Msg. received!\n\n\n");
    printf(" Msg. nr.: %lu", receiveUnion.data.messageNr);
    printf("\n\n\n Temp: %.3f C", receiveUnion.data.temperature);
    printf("\n\n Hum:  %.3f P", receiveUnion.data.humidity);
}

Transmit mode

In transmit mode a new packet is being scheduled and sent. The temperature and humidity data can be read through the Si7013_MeasureRHAndTemp function. A division by thousand is necessary to get the actual values. After combining the packet to send, we should set the FIFO up and start the scheduled transmit. The delay in general is recommended to give the LCD time to refresh. A 0.5 - 1 second delay also helps the readability of the display. This is the point where we should also set the txPacketPending flag – if scheduling the transmit didn't result in an error –, as we wouldn’t want to send another packet while the previous one is pending, nor do we want to start receiving until the last transfer is not complete. At this point the application waits until the packet is pending, and only after the transmit is complete it writes "Message sent" on the screen along with the appropriate message number.

if (packetTx) {
    uint32_t tempHum;
    int32_t tempTemp;
    Si7013_MeasureRHAndTemp(i2cInit.port, SI7021_ADDR, &tempHum, &tempTemp);
    sendUnion.data.humidity = (float) tempHum / 1000;
    // We get the humidity in millipercent
    sendUnion.data.temperature = (float) tempTemp / 1000;
    // We get the temperature in millicelsius
    sendUnion.data.messageNr++;
    RAIL_Idle(railHandle, RAIL_IDLE, true);
    uint16_t dataLength = sizeof(sendUnion.raw);
    RAIL_SetTxFifo(railHandle, &sendUnion.raw[0], dataLength, dataLength);
    if (RAIL_StartScheduledTx(railHandle, channel, RAIL_TX_OPTIONS_DEFAULT,
    &scheduleTxConfig, NULL) == RAIL_STATUS_NO_ERROR) {
        // Start a scheduled (delayed) transmit with the custom parameters set before
        txPacketPending = true;
        // Mark the packet to be pending with this flag if there were no errors
    } else {
        printf("\f\n\n\n Send ERROR!\n\n\n");
    }
    // Wait until the packet is sent
    while (txPacketPending) {
        ;
    }
    printf("\f\n\n\n Msg. sent!\n\n\n");
    printf(" Msg. nr.: %lu", sendUnion.data.messageNr);
}

Receive mode

The receive part of the main while loop will be perfect for our project as it was written for the simple TRX, no modification is needed here.

Conclusion

This tutorial showed how to integrate drivers usually not included in RAIL example applications. However there are plenty examples available for the EFM32 controllers, it's not always straightforward which steps are required to use the available peripherals when you are working with an EFR SoC . We saw how simply we can modify a working RAIL example to send and also display something variable and useful, by showing the appropriate hardware configuration, the necessary files and initializations, and the functions to utilize the peripherals.

API introduced in this tutorial

Functions

• RETARGET_TextDisplayInit()
• RAILCb_Generic()
• RAIL_HoldRxPacket()
• RAIL_GetRxPacketInfo()
• RAIL_CopyRxPacket()
• RAIL_ReleaseRxPacket()
• Si7013_Detect()
• Si7013_MeasureRHAndTemp()
• RAIL_Idle()
• RAIL_SetTxFifo()
• RAIL_StartScheduledTx()

Note: the correct solution for this example is the rail_temp.c below, please disregard the other attachment.

Pre-requisite readings:

• QSG138: Getting Started with the Silicon Labs Flex Software Development Kit:
  • 4.2 Working with Connect Host/NCP Examples
• AN844: Guide to Host/Network Co-Processor Communications Using Silicon Labs Thread and Connect
• UG115: ASHv3 Protocol Reference

Bear in mind that host application requires a UNIX-like operating system (tested with Debian Linux) to compile and run the executable.

NCP stands for ‘Network Co-processor’. By this method the customers can use a common firmware on the EFR32 SoC and control the NCP through UART interface from their application running on a different host equipment.

The setup has two separate and mostly independent part:

• EFR32 firmware:

• Host application:

The EFR32 firmware is a ready-to-use example, fully pre-configured, it is only necessary to configure the radio parameters if the default settings are not suitable and compile / load the code to the EFR32 device if there is no any special requirement. There are two example projects regarding UART based NCP, the software and the hardware flow control versions – although these examples are almost the same except the definition which controls SW / HW handshaking method for the selected UART.

Note: as of writing this manual, HW flow control seems to work with WSTK only.

Open one of the NCP UART projects (SW or HW flow control) which suits the needs and go through the configuration / generation / compilation process. After the compiled firmware downloaded to the SoC and started, the device immediately available to receive NCP commands from the host.

 

Although, it is possible to use any Connect project with NCP, in most of the cases customers uses the host as a coordinator, thus the Host Sink example project selected since this is a perfect boiler-plate code to develop / implement own application.

Although, a host application can run on almost any architecture, the application examples in the SDK are provided only for UNIX-like operating systems.

This example assumes that the customer has a UNIX-like environment set up with Simplicity Studio and GCC for the host (target) available. It is also possible to cross-compile the application to different target than the host but setting up that kind of environment is out of the scope of this document.

 

Open the Connect (Host): Sink example project. Since this project is not part specific, delete the selected part if any:

Click on generate, which will create the necessary files as in case of any other projects. Since the host GCC is usually not configured, executing the compilation process will print an info message and will no compile the code:

The current IDE does not support host target compilation, however, at that point it is possible to compile the application from a terminal console. Open a terminal and navigate to the project’s root directory and issue the make -f sink-host.mak command. The project should be compiled cleanly and an executable named sink-host-unix-host app should be created in the directory build-sink-host-unix-host. By starting the application, a text console should appear on which it is possible to type the application commands and they should work as if it was the serial console of a Sink / SoC configuration:

./sink-host-unix-host-app --uart /dev/ttyACM0
Reset info: 0x0B (SOFTWARE)
ASHv3 is up
INIT: sink-host

sink-host>

 

By default, the Host Sink application works the same as the SoC version of Sink example, the user can issue the commands to form a network or enable joining (See: ‘How to setup and use a Connect Sink / Sensor example project’).

 

Since the ASHv3 protocol is fully documented, customers can implement a host code on their own hardware – not necessarily need to use the structure of the provided examples.

 

This tutorial builds on the following tutorials:

• RAIL Tutorial 1: Introduction and init
• RAIL Tutorial 2: Transmitting a packet
• RAIL Tutorial 3: Event handling
• RAIL Tutorial 4: Combining transmit and receive

Please read them first if you haven't. You should also have some experience with SWD based debugging in Simplicity Studio.

You can find other tutorials on the table of contents site.

EFR32 Wireless Geckos, as any modern MCU, supports on-chip debugging. However, when debugging radio problems, it's often not enough. Generally, the problem is that some bugs originate from the real time nature of the radio: When stopping the radio at a breakpoint, you change the behavior of the target. Also, you might need information from multiple targets at the same time. We recommend RAIL/EFR32 debug techniques for these problems in this tutorials, as well as other RAIL specific debug features.

RAILTest

While the original goal for RAILTest was to test the RAIL library, it can be a very useful tool for software development as well. In most cases, you probably want to concentrate on either receive or transmit, and need something to play the role of the other side. RAILTest can be very simply used for that. Just set up the right config, and it will immediately start in receive mode, printing the received messages with timestamps (useful for checking synchronized transmits), and it will transmit a single message on PB0 button press, or start transmitting periodically on a long press of PB0.

Debugging with SWD

EFR32 provides SWD as the debug interface. You can use breakpoints and read register values when the MCU is halted, just like any other EFM32. However, you should be careful using this tool for debugging the radio.

Keep in mind, that the radio is fast: if you put a breakpoint to the RAIL event handler, you can stop the MCU while it's receiving/transmitting a packet, which could result bugs that normally wouldn't happen, e.g. the timestamps could be completely wrong, or you can run into buffer overflow/buffer underflow events.

You could also see some very strange phenomenons when debugging the radio: You might see that values stored in the memory changes, even though MCU is halted. That is caused by the radio co-processor of EFR32 (sometimes called sequencer), which is used to help with time-critical event handling of the radio, and shares some memory with the main MCU.

Generally, I would recommend not to put breakpoints into the RAIL event handler, set temporary flags instead, and stop the application in the main loop when it's safe to check the values. Another good technique is to put past events into a queue:

volatile RAIL_Events_t eventQueue[5];
void RAILCb_Generic(RAIL_Handle_t railHandle, RAIL_Events_t events)
{
    //handle events
    for(int i=1;i<5;i++){
        eventQueue[i-1] = eventQueue[i];
    }
    eventQueue[4] = events;
}

This helps a lot to figure out the flow that resulted the problem you're debugging.

Assertion

RAIL provides an assertion mechanism. For example, if you try to set a channel on a frequency which is not available from the radio configuration, you'll get a RAIL_ASSERT_FAILED_SYNTH_VCO_FREQUENCY assert. To catch asserts, you should implement the following function:

RAILCb_AssertFailed(RAIL_Handle_t railHandle, RAIL_AssertErrorCodes_t errorCode) {
    while(1);
}

It's a good idea to stop normal operation on assert - in a production application, you probably want to reset from it. The default implementation is what you see above, but it's in the closed source rail library, so you cannot access the errorCode, which could be really helpful. If you put a breakpoint here, you can also see the callstack of the assert, where you might not understand all levels (as part of it is probably in the closed source library), but at least you can see the original source of the assert.

Since the default implementation is an infinite loop, an unhandled assert will result a locked up program - if you see something like this, implement the assert callback first. Even if you don't understand the root cause, our support team could help you much easier, if you provide the assert code and even better if you can provide the call stack.

Debugging with GPIOs and PRS channels

You probably already used this technique to debug time-critical problems: toggle a GPIO when something happens, and use a logic analyzer or an oscilloscope to analyze it. EFR32 can help further with radio specific PRS channels, wired to GPIOs (taken from the EFR32 page of RAIL API documentation):

Signal	RAILTest name	Summary
PRS_RAC_ACTIVE	RACACTIVE	Radio enabled
PRS_RAC_TX	TXACTIVE	Transmit mode enabled
PRS_RAC_RX	RXACTIVE	Receive mode enabled
PRS_MODEM_FRAMEDET	FRAMEDETECT	Frame detected (Syncword received)
PRS_MODEM_PREDET	PREAMBLEDETECT	Preamble detected
PRS_MODEM_TIMDET	TIMINGDETECT	Timing detected
PRS_MODEM_FRAMESENT	FRAMESENT	Frame sent
PRS_MODEM_SYNCSENT	SYNCSENT	Syncword sent
PRS_MODEM_PRESENT	N/A	Preamble sent

If a GPIO is configured for a given PRS signal, it will go high when the signal is active. I.e. if you configure PRS_RAC_TX to a gpio, the signal will be high during transmission. In RAILTest, you can set these up to a limited number of pins:

setDebugSignal PC11 TXACTIVE

You can use setDebugSignal help for available GPIOs (and signals).

To set it up in c, you can use the following snipplet, if you use the RAIL-HAL plugin. If you don't want to use that plugin, just copy the implementation from there.

CMU_ClockEnable(cmuClock_GPIO, true);
GPIO_PinModeSet(gpioPortC, 11, gpioModePushPull, 0);
halEnablePrs(10, 5, PRS_RAC_TX>>8, PRS_RAC_TX&0xff);

The first two parameter of halEnablePrs is the PRS channel, and the location where to wire it. EFR32s have 12 PRS channels, and all of them can be wired to many GPIOs. You can find these in the datasheet, under Pin Definitions/Alternate functionality overview/PRS_CHx.

However, if you work on WSTK, there's a simpler method: You can reuse the preconfigured GPIOs available for RAILTest - these cover pretty much all free GPIOs. I usually use the following code snippet, so I don't have to pair GPIOs with PRS locations:

#include "em_cmu.h"
#include "em_gpio.h"
#include <string.h>
#include "hal_common.h"

void enablePrs(char *debugPinName, uint16_t prsSig){
  uint32_t count;
  uint32_t pin = 0;
  const debugPin_t *debugPins = halGetDebugPins(&count);
  while ( pin<count && strcmp(debugPins[pin].name, debugPinName) ){
    pin++;
  }
  if (pin<count){
    CMU_ClockEnable(cmuClock_GPIO, true);
    GPIO_PinModeSet(debugPins[pin].gpioPort, debugPins[pin].gpioPin, gpioModePushPull, 0);
    halEnablePrs(debugPins[pin].prsChannel, debugPins[pin].prsLocation,
                 prsSig>>8, prsSig&0xff);
  }

}

void setupDebugPins(){
  enablePrs("PC11", PRS_RAC_TX);
}

You can also use the comments in hal-efr32/hal_efr.c to figure out where are these wired on a WSTK:

{
  .name = "PC10", // EFR32xG1/EFR32xG12/EFR32xG13 - EXP_HEADER15, WSTK_P12
  .prsChannel = 9, // PRS 0/12 9/15 10/4 11/3
  .prsLocation = 15,
  .gpioPort = gpioPortC,
  .gpioPin = 10
},

This means it's on the EXP connector, pin 15, or P12, on the connector below (and above) the display. Note that not all pins are available on all boards, e.g. PC9 is only available on xG12 (xG14 is never mentioned, but it's always pin compatible with xG1). Sometimes these pins share functionality, e.g. PF4 is also LED0 on xG1/xG13/xG14.

PRS signals can be extremely useful when working on multiple devices:

In the logic analyzer capture above (of a PRS-modified duty cycle example), you can see whlie device 2 starts transmitting, and how device 1 locks on that signal.

PRS signals can be also used to measure state transition times, which is often very important in time critical applications. Note however, that even though the RXSTATE signal is driven high, the radio and RAIL could still needs some time to complete the state transition, so it might be possible that you can't detect a signal at the beginning of the rx window, or you're already leaving rx mode when an event is triggered, making it useless.

API introduced in this tutorial

Functions

• RAILCb_AssertFailed()

Types and enums

• RAIL_AssertErrorCodes_t

      EFR32MG12和后续的器件（MG13, MG14）在规格书里列出了使能电压调节的EM2睡眠电流。然而，EM2缺省配置为电压调节功能被禁止了。要使能电压调节功能，选择硬件配置文件的"DefaultMode Peripherals" 标签并点击EMU外设，也就是要把EMU设为check状态。

 

 

 

 

 

 

 

   

    在属性窗口里面，改变属性"EM2/3 voltage scaling level"的"Fast wake-up"值为"Low power"。

   

 

 

 

 

 

   

    点击Save按钮，然后产生和编译你的工程。

    注：对于在AppBuilder里已选为睡眠类型的器件，使能EM2模式下的电压调节的特性需求已注册。

The most common setting for the CC1120 radio is the 50kbps, 2GFSK, IEE 802.15.4G mode. In this guide we will go through the necessary steps to configure the EFR32 radio to be able communicate with the TI radio.

1. First, create a RAILtest project and open the .isc file. The values, which are different from the default ones are highlighted with yellow color. Select Custom settings profile, set the Base Channel Frequency to match the frequency band of your board. In the Modem section set the bitrate to 50kbps, the deviation to 25kHz. Make sure that the Modulation Type is FSK2 and the Shaping Filter is Gaussian (2GFSK modulation).

   

    

2. Open the Packet settings. On the Frame General tab change the Frame Length Algorithm to VARIABLE_LENGTH and the Frame Bit Endian to MSB_FIRST

   

    

3. Go to the Frame Variable Length tab and set it up like this: Variable Length Bit Endian: MSB_FIRST; Variable Length Byte Endian: MSB_FIRST; Maximum Length: 63 bytes; Variable Length Bit Size: 8 bits.

   

    

4. Switch to the CRC tab. CRC Byte Endian should be MSB_FIRST; CRC Input Bit Endian MSB_FIRST; set the CRC Seed to FF FF.

   

    

5. On the Whitening tab select Whitening Polynomial PN9_BYTE and set the Whitening Seed field to 01 FF.

   

    

6. Now let’s set up the content of the packet. There are no changes in the Preamble, leave all values to their default.

   

    

7. Syncword: set the Sync Word Length to 32 bits and the Sync Word 0 to 93 0B 51 DE.

   

    

8. Header: Enable CRC Header, set Header Size to 1 byte and enable Whiten Header.

   

    

9. Payload: Tick the Payload Whitening Enable option.
   
10. Now save the isc file and click Generate. When it is done compile the RAILtest project. Connect a WSTK board with an appropriate radio board and download the binary to the EFR32 chip.

The EFR32 side is ready, now let’s see the CC1120 settings.

1. Connect your eval board to the PC and start the SmartRF Studio. On the main screen select CC1120.
2. In the Typical Settings frame open the Generic 868/915/920MHz category and select the Bit rate: 50kbps, 2-GFSK, IEEE 802.15.4G (868) setting
3. In the RF Parameters section enable the Whitening option

To test the link, open a terminal program (TeraTerm or similar) and connect to the WSTK’s virtual COM port.

In the SmartRF Studio click switch to the Packet RX tab and click the Start button. Type ‘tx 10’ in the terminal program and the EFR chip will send out 10 packets. In the CC1120 device control panel you should see the packets arriving.

To test the other direction type ‘rx 1’. This will switch the EFR32 to receiving mode. In the control program of the TI chip click on the Packet TX tab. Untick the Add Seq. Number option, set Packet Count to 1, select Hex and type in the text box the content of the packet: ’01 23 45 67 89 AB CD EF’. Click on the Start button to send the packet. The received data will be displayed in the terminal program.

 

The available reference matching networks for the EFR32 wireless Gecko family at the sub-GHz frequency region utilize the so-called direct-tie topology where the TX and RX paths are directly connected to each other without using external RF switch. In order to be able to insert a SAW filter into this matching structure it is recommended to separate the TX and RX paths, since it is not suggested utilizing SAW filter in the TX path, because of:

- the expected power efficiency degradation in TX mode due to the considerable insertion loss of the SAW filters,

- SAW filters are typically designed for low power levels, i.e. would yield TX power limitation, 

- SAW filters typically do have weaker attenuation at the higher frequencies, i.e. at the RF harmonics, so discrete LPF would always be recommended. 

The recommended schematic structure for EFR32 with SAW filter is shown below. 

- TX path match is kept from the reference matches available, recommended component values are shown in AN923 or refer to the existing reference designs.

- The order of the LPF section may be changed based on the power level, harmonic suppression requirements. 

- RX path match utilizes a standard 4-element discrete matching balun network, similarly as detailed in AN643. Simulated component values are shown in the table below.

- RF switch is also being used in order to separate the TX and RX paths' matches, while being connected to the same antenna port.

- SAW filter's separate matching network may not be needed (LW1, LW2, CW1, CW2, CW3 and CW4) - refer to the given SAW filter datasheet.

 

Introduction

The goal of this tutorial is to help you get started with RAIL, the C API for embedded softwares for Silicon Labs EFR32 Wireless Geckos.

To read it, you should have some experience with embedded C: You should know how to handle interrupts, what volatile means, etc.

While we try to avoid using it, you might need some experience with radios as well. It definately helps if you know what preamble or sync word is.

The tutorials should be read together with the RAIL API documentation. You can find it in Simplicity Studio, if you select Flex SDK:

If you find any contradiction between the tutorials and the API documentation, it's very likely that the tutorials are wrong.

Getting Started

You should start with these tutorials. All others are based on these, as these are the minimum to develop useful applications on RAIL.

• RAIL Tutorial 1: Introduction and init
• RAIL Tutorial 2: Transmitting a packet
• RAIL Tutorial 3: Event handling
• RAIL Tutorial 4: Combining transmit and receive

Basic tutorials

These tutorials are common and basic features, you should read them if you start working on a project which uses RAIL.

• Time, scheduling and sleep
• Calibrations
• Debugging

Advanced tutorials

These tutorials describe features that are rarely needed - you should know their existence, but you probably won't use them all in your application. Generally, you should read them if you think you need them.

• Coming soon (first topic will be likely FIFO mode/direct mode)