Question:  I've been getting 'ERROR: No application properties area found in application'' when trying to generate GBL files using simplicity commander. What are the steps to add Gecko Bootloader compatibility to a project that is using the RAIL API? 

Answer: Below are the two options to create the .gbl file for RAIL project without errors.

Option 1: Force GBL creation with default application properties using Simplicity commander. Commander will now insert a default struct into the GBL file(not s37 application file)

More information about force command can be found in the UG162 Simplicity Commander Reference Guide

Option 2: To enable the security features, we must add application properties struct to the RAIL project

When using Simplicity Studio v4 with ARM GCC toolchain copy application_properties.c file to the project, now add the path to application_properties.h(include in build) and change the APP_TYPE to MCU from Bluetooth App.

Location of application_properties.c file for gecko SDK v2.4 - C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.4\app\bluetooth\appbuilder\sample-apps\common

then, add "KEEP(*(.application_properties))"  to the linker file(.ld) as below. This will enable the access to ApplicationProperties.

SECTIONS
{
.text :
{
KEEP(*(.vectors))
__Vectors_End = .;
__Vectors_Size = __Vectors_End - __Vectors;
__end__ = .;
KEEP(*(.application_properties))

*(.text*)

KEEP(*(.init))
KEEP(*(.fini))

Now generate .gbl file using simplicity commander. More information about using simplicity commander can be found in the UG162 Simplicity Commander Reference Guide

        所有RAIL示例项目都依赖于UART，因为retargetserial.c 是由HAL library插件自动添加到项目中的，就连一些根本没有用到UART的项目(如Simple TRX )都依赖于UART。

        在AppBuilder 或Hardware Configurator 中禁用UART及所有串口的相关选项(如下图)，都不能解除对UART的依赖。

        其根本原因是retargetserial.c 包含了retargetserialhalconfig.h ，如果hal-config.h中没有有效UART定义的话就会有触发#error "Invalid UART type"。编译就会报如下(或相似)的错误:

        解决方法是从项目中移除retargetserial.c (位于hal-efr32目录) 。移除后即可成功编译了。

        有一点要注意，通过AppBuilder重新生成项目后,一定要记得重新移除这个文件。

        英文原文：https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/11/10/remove_uart_dependen-tRaj

All Silicon Labs EFR32 radio board equipped with external SPI flash memory. Although, the standby current consumption of these devices are low some application need to eliminate even this amount of current consumption to reach extremely low power consumption (the achievable current consumption of a Connect based application exploiting Connect's lowest power mode (EM2) is ~2-4uA)). This mode of the SPI flash called "Deep Power Down" mode, which is available by sending the 0xB9 command to the flash (on the SPI interface).

First, the SPI Flash plugin must be enabled in AppBuilder (Plugins tab):

Don't forget to re-generate project files.

Beside enabling the SPI Flash plugin it is necessary to add the initialization and deep power down command to the project by calling the two API functions below:

• halEepromInit()
• halEepromShutdown()

It is practical to call these functions at startup of the application, for example from emberAfMainTickCallback() which located in flex-callbacks.c like in the example below:

void emberAfMainInitCallback(void)
{
  emberAfCorePrintln("INIT: %p", EMBER_AF_DEVICE_NAME);
  emberAfCorePrintln("\n%p>", EMBER_AF_DEVICE_NAME);

  halEepromInit();
  halEepromShutdown();

  emberNetworkInit();
}

After applying the above the current consumption should be reduced by ~8-10uA.

In some cases customer wants to build a project directly by IAR Embedded WorkBench. Since the Simplicity Studio generated IAR project files may have some mistakes and may not be able to fix by Simplicity Studio design team in a short time, here is a workaround solution.

Take railtest_efr32 project as an example, after we generate it with IAR toolchain in Simplicity Studio, we should also check if it can pass compiling/building process in Simplicity Studio with IAR toolchain firstly. It is supposed the building with SS should be OK.

Then open the project railtest_efr32.eww with IAR workbench directly. The compile may fail, we found below errors. Test on Flex SDK 2.4.1.0. If you use Flex SDK 2.3.1.0, you may only have issue 2.

1, File link mistake.

2, EFR32MG12P332F1024GL125.icf cannot found.

3, Files is not included.

If you also found it failed to build the project, you could try below modifications, after doing these 2 steps, the IAR Embedded WorkBench compiling was supposed to be successful.

1, In file railtest_efr32.ewp. Make the files link correct and entirety.

Change the line

$PROJ_DIR$\..\railapp\railapp_antenna.c

to

$PROJ_DIR$\railapp_antenna.c

Add gpio_ci.c and zwave_ci.c into the project.

After changed, it will look like below:

2, Browse to Options-->Linker-->Config-->Linker configuration file, Uncheck “override default” option. Make the icf link correct.

After all the changing, you will can compile success and get a screen like this:

    现有的EFR32无线小壁虎系列sub-GHz频段参考匹配网络中，使用所谓的直接相连的拓扑结构，即Tx和Rx通路直接连在一起而不使用外部的射频开关。为了在参考匹配网络中插入SAW 滤波器/ RF开关或 FEM模块，需要将Tx通路与Rx通路分离开来，这是因为不建议在Tx通路使用SAW滤波器，具体原因如下： 

- SAW滤波器相当大的插损会降低期望的功率效率，

- SAW滤波器典型应用是低功率等级，也即会产生功率限制问题，

- SAW滤波器通常对高频率信号（也即RF谐波成分）衰减相对较弱，因此总是推荐使用分立LPF。

    EFR32带SAW滤波器的推荐原理图结构如下：

- Tx通路的匹配保持现有的参考匹配电路，推荐匹配元件值已在AN923中说明，或参考现在的参考设计。

- LPF低通滤波器部分可以基于功率水平，谐波抑制的要求来改变。

- Rx通路匹配利用一个标准的4元件分立巴伦匹配网络，相应的在AN643里面有详细说明。仿真元器件值如下表所示。

- RF开关被用来分开TX和RX通路的匹配，这两个通路被连接到相同的天线端口。

- SAW滤波器独自的匹配网络并非必须的 (LW1, LW2, CW1, CW2, CW3 and CW4)，具体请参考给定SAW滤波器规格书。

    对于只用RF开关的设计，上述原理图是可用的，不焊接SAW滤波器及其匹配元件即可。但是，推荐在4元件离散巴伦单端端口和RF开关之间串入旁路/DC隔离电容。

    下图所示是一典型的带FEM的设计，在这里，RF开关可被FEM取代。SAW滤波器在下图没显示出来，但如果使用的话，可将其应用在FEM的RX端口上。在FEM（带LNA）设计中推荐SAW滤波器放在FEM的分立RX端口上，并确保在接收通路上RF模块的顺序如下：天线 --> 分立 LPF(因TX谐波抑制需要) --> SAW滤波器 --> FEM LNA --> 4元件分立巴伦匹配网络 --> EFR32 LNA。这种方法可确保即使在嘈杂的环境中也有强悍的接收性能。在无噪声环境中，如果将SAW滤波器置于4元件匹配巴伦和FEM的LNA之间，则可以实现更好的链路预算。芯科建议使用上述方法，因为将LNA引入接收器路径一般会产生更好的灵敏度，但会导致更差的线性和阻塞性能。如果可以保证无噪声环境，那么SAW滤波器在设计中是不必要的。

    同样，对于在Tx通路上的分立匹配方案（也即去掉EFR32和FEM之间的外部陶瓷巴伦），请参考以下链接的KBA：

https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/11/06/discrete_matchingso-IKyv

  Connect 支持NCP(网络协处理器)工作模式(通过UART接口)。这种情况下应用与协议栈分别置于不同的设备上。协议栈运行在EFR32设备(target)上，而应用运行在另一MCU/CPU(host)。

  在当前的应用，当NCP有一些打印操作后，通信会宕在目标NCP侧。

  为避免这种问题，应在ncp-main/ncp-main.c中，在ThreadMain(NULL);这一行前加上emberSerialWaitSend(APP_SERIAL);

如下：

int MAIN(void)
{
#if defined(__CONNECT_CONFIG__) && !defined(CORTEXM3_EMBER_MICRO)
  emberAfMain();
#endif

  halInit();
  INTERRUPTS_ON();
  emberSerialInit((uint8_t)APP_SERIAL, (SerialBaudRate)APP_BAUD_RATE, (SerialParity)PARITY_NONE, 1);

  emberSerialPrintfLine(APP_SERIAL, "%s-app ready", emAppName);
  emberSerialPrintfLine(APP_SERIAL,
                        "channel %u (0x%x), node id 0x%2x, pan id 0x%2x",
                        emberGetRadioChannel(), emberGetRadioChannel(),
                        emberGetNodeId(), emberGetPanId());
  emberSerialPrintf(APP_SERIAL, "%s> ", emAppName);

  emberSerialWaitSend(APP_SERIAL);

  // Call the main NCP thread. This should never return
  ncpThreadMain(NULL);

  // should never hit this, but here to suppress compiler warning
  return 0;
}

One of the main draws of using an EZR32 device is its low current consumption in low energy modes. When using EM2, EM3, or EM4, you obviously want the device to consume as little current as possible. However, just entering these modes will not shut the radio down (these energy modes only affect the MCU core), so the radio will continue to draw large amounts of current (relatively speaking), even when the MCU is in a low power mode.

There are two options for decreasing the radio current for low power modes:

1. Turn the radio off completely by asserting the SDEN pin.
2. Issue a command to the radio to place it into the SLEEP state.

#1 consumes the least amount of current (30nA), but has the drawback of requiring a complete re-initialization of the radio (which takes ~30ms). #2 consumes slightly more current (50nA), but allows the radio to be ready much sooner (~500us), and is the preferred method.

In the ezradio api, you can use the ezradio_change_state function to move the radio between sleep and active states.

If you're using a low energy mode in the EZR32 device, such as EM3, you can 'wrap' the energy mode function in sleep / active state commands to minimize current consumption of the entire device (MCU and Radio):

ezradio_change_state(EZRADIO_CMD_CHANGE_STATE_ARG_NEXT_STATE1_NEW_STATE_ENUM_SLEEP);
EMU_EnterEM3(false);
ezradio_change_state(EZRADIO_CMD_CHANGE_STATE_ARG_NEXT_STATE1_NEW_STATE_ENUM_READY);

Note, you may also need to disable the pull-down on the INT pin as this sometimes causes additional leakage, for example:

ezradio_change_state(EZRADIO_CMD_CHANGE_STATE_ARG_NEXT_STATE1_NEW_STATE_ENUM_SLEEP);
GPIO_PinModeSet((GPIO_Port_TypeDef) RF_INT_PORT, RF_INT_PIN, gpioModeInput, 0);
EMU_EnterEM3(false);
GPIO_PinModeSet((GPIO_Port_TypeDef) RF_INT_PORT, RF_INT_PIN, gpioModeInputPull, 0);
ezradio_change_state(EZRADIO_CMD_CHANGE_STATE_ARG_NEXT_STATE1_NEW_STATE_EN

Connect supports NCP (Network Co-Processor) mode operation (through UART interface). In that case application and the stack functions are located in different device. The stack runs on the EFR32 device (target) and the application runs on an different MCU / CPU (host).

In the current implementation the communication hangs on the NCP target side right after it prints a few characters.

To eliminate the issue, add <code>emberSerialWaitSend(APP_SERIAL);</code> right before the line <code>ncpThreadMain(NULL);</code> in <code>ncp-main/ncp-main.c</code> as it added below:

int MAIN(void)
{
#if defined(__CONNECT_CONFIG__) && !defined(CORTEXM3_EMBER_MICRO)
  emberAfMain();
#endif

  halInit();
  INTERRUPTS_ON();
  emberSerialInit((uint8_t)APP_SERIAL, (SerialBaudRate)APP_BAUD_RATE, (SerialParity)PARITY_NONE, 1);

  emberSerialPrintfLine(APP_SERIAL, "%s-app ready", emAppName);
  emberSerialPrintfLine(APP_SERIAL,
                        "channel %u (0x%x), node id 0x%2x, pan id 0x%2x",
                        emberGetRadioChannel(), emberGetRadioChannel(),
                        emberGetNodeId(), emberGetPanId());
  emberSerialPrintf(APP_SERIAL, "%s> ", emAppName);

  emberSerialWaitSend(APP_SERIAL);

  // Call the main NCP thread. This should never return
  ncpThreadMain(NULL);

  // should never hit this, but here to suppress compiler warning
  return 0;
}

All RAIL example projects rely on UART since retargetserial.c is added to the project automatically by HAL library plugin - even it the particular example does not use UART at all (like Simple TRX ).

Disabling UART and all the serial port related items in AppBuilder or Hardware Configurator (see the screenshots below) does not result in removing the UART dependency.

The root cause is that retargetserial.c includes retargetserialhalconfig.h which end in #error "Invalid UART type" if no valid UART is defined in hal-config.h. Thus the compilation will fail with the following (or similar) error:

The solution is to exclude retargetserial.c (which is located in hal-efr32) from the project. After exclusion the project should compile cleanly.

There is one drawback however, regenerating the project files by AppBuilder will reset the exclusion, thus the file must be exclude after generation again.