 |
Wirepas SDK
|
|
Wirepas SDK
|
As a prerequisite for this guide, you must be able to successfully build one of the provided application example from the SDK.
This page contains following sections:
This page contains following sections:
For Windows installation, we're using Windows Subsystem for Linux. There are other possible options, such as Cygwin or MinGW but they are not covered here.
First, install Windows Subsystem for Linux according to installation guidelines. Choose Ubuntu installation.
After done that and system is update, proceed following in bash:
Update the system:
This page contains following sections:
Using GCC Arm toolchain version 7.2.1 (7-2017-q4-major) is recommended to be used. Download the toolchain (in some directory of your own choice):
And unpack the downloaded package:
Now, there is a subfolder called gcc-arm-none-eabi-7-2017-q4-major containing necessary tools. You may move the folder to desired location. Modify PATH to contain bin subfolder, for example here .
After that, you can verify that compiler toolchain has installed by typing:
which should produce following output:
Here are other software components that should be installed:
Install required Python libraries:
For Ubuntu-based variants, follow guideline used in Windows installation using WSL.
The custom_app application is a simple application that sends a periodically incrementing counter value over the Wirepas network.
The application can be built with the following command:
After execution of this command, you should find the final_image_custom_app.hex under build/<target_board>/<app_name> folder.
When using the board for the first time, the image named final_image_<app_name>.hex generated by the build process must be flashed. This image contains the Wirepas bootloader and a scratchpad composed by the Wirepas Mesh stack and the application. This step must be done on each new board.
On next boot, the stack and the application will be flashed from the scratchpad to their dedicated flash areas.
Using the flash mechanism is a convenient way to develop the application as long as the devices are accessible and not in high volumes. When updating a large network, using OTAP is more practical.
This page contains following sections:
For information on how to flash Nordic nRF52xxx devices, check out nRF5x Command Line Tools User Guide
First, install Segger J-Link Software and Documentation Pack
For information how to use Segger Jlink command-line executable (named either JLink.exe or Jlinkexe according to your operating system), refer to J-Link Commander.
The following information should be used.
| Device architecture | Radio profile | JLink device type |
|---|---|---|
| EFR32xG12 | 2.4 GHz/SubGhz | EFR32FG12PxxxF1024 |
Note: usually interface is SWD but it depends on the hardware design. For example: Flex Gecko uses SWD.
Here, couple of example J-Link Commander Command files that can be used as a reference:
Programming EFR32xG12 device:
You may also need to recover the device when you need to:
The recovery removes flash write protection mechanism and whole flash contents. Following command for recovering is issued when using JLink commander:
The nRF52 chip version supported by Wirepas Mesh has minimum 512kB of flash and 64kB of RAM.
This page contains following sections:
As stated in description of memory partitioning, the available flash memory for application is limited by size of the memory area that is used commonly for application and also scratchpad image. If application size is too large, there is possibility that large scratchpad image will override application image. The default maximum size of the application has been set so that it is always safe to use scratchpad image that will contain both firmware and application.
The recommended maximum size of flash memory for an application is 40kB.
Allocated RAM memory for application by the processor is following:
| Processor | RAM memory |
|---|---|
| nRF52832 | Up to 16 kB (8 kB by default) |
| nRF52840 | 188 kB |
Some peripherals are used by the Wirepas Mesh stack and cannot be used by the application.
| Peripheral | Associated interrupt (from file mcu/nrf52/vendor/nrf52.h) |
|---|---|
| Power | POWER_CLOCK_IRQn |
| Radio | RADIO_IRQn |
| Timer0 | TIMER0_IRQn |
| WDT | WDT_IRQn |
| Rtc1 | RTC1_IRQn |
| ECB (AES) | ECB_IRQn |
| PPI (Channels 0, 1 and 2) | None |
All the internal interrupt of cortex M are handled by the stack directly (NMI, HardFault,...)
Some peripherals are used by the stack but can also be accessed by the application. There is a dedicated API to reserve these peripherals.
These peripherals must be reserved through the API before being used and the application must initialize them each time after reserving it. In fact, the stack may configure them differently.
It is also important to avoid long reservation of theses peripherals to let the stack use them for its own purpose.
| Peripheral | Reservation ID (from app_lib_hardware_peripheral_e) |
|---|---|
| ADC | APP_LIB_HARDWARE_PERIPHERAL_ADC |
| Temp | APP_LIB_HARDWARE_PERIPHERAL_TEMPERATURE |
All the other peripherals not listed above are free to be used by the application.
Following chip variants (at 2.4 GHz only) are supported:
This page contains following sections:
As stated in description of memory partitioning, the available flash memory for application is limited by size of the memory area that is used commonly for application and also scratchpad image. If application size is too large, there is possibility that large scratchpad image will override application image. The default maximum size of the application has been set so that it is always safe to use scratchpad image that will contain both firmware and application.
The recommended maximum size of flash memory for an application, according to processor type is following:
| Processor | Flash memory |
|---|---|
| efr32xg12pxxxf1024 | 256kB |
| efr32xg12pxxxf512 | 40kB |
| efr32xg13pxxxf512 | 40kB |
Allocated RAM memory for application, by the processor is following:
| Processor | RAM memory |
|---|---|
| efr32xg12pxxxf1024 | 72kB |
| efr32xg12pxxxf512 | 8kB |
| efr32xg13pxxxf512 | 16kB |
Some peripherals are used by the Wirepas Mesh stack and cannot be used by the application.
| Peripheral | Associated interrupt (from chip vendor files) |
|---|---|
TIMER0 | TIMER0_IRQn |
RTCC | RTCC_IRQn |
WDOG0 | WDOG0_IRQn |
CMU | CMU_IRQn |
CRYPTO0 | CRYPTO0_IRQn |
All the internal interrupt of cortex M are handled by the stack directly (NMI, HardFault,...)
Some peripherals are used by the stack but can also be accessed by the application.
These peripherals must be reserved through the API before being used and the application must initialize them each time after reserving it. In fact, the stack may configure them differently.
It is also important to avoid long reservation of theses peripherals to let the stack use them for its own purpose.
| Peripheral | Reservation ID (from app_lib_hardware_peripheral_e) |
|---|---|
| ADC0 | APP_LIB_HARDWARE_PERIPHERAL_ADC |
All the other peripherals not listed above are free to be used by the application.
[3] WP-RM-108 - OTAP Reference Manual
[4] https://github.com/wirepas/wm-sdk/blob/master/source/reference_apps/dualmcu_app/api/DualMcuAPI.md