STMicroelectronics STM32WL User Manual

AN5406

Application note

How to build a LoRa® application with STM32CubeWL

Introduction

This application note guides the user through all the steps required to build specific LoRa® applications based on STM32WL Series microcontrollers.

LoRa® is a type of wireless telecommunication network designed to allow long-range communications at a very low bitrate

and to enable long-life battery-operated sensors. LoRaWAN® defines the communication and security protocol that ensures the interoperability with the LoRa® network.

The firmware in the STM32CubeWL MCU Package is compliant with the LoRa Alliance® specification protocol named LoRaWAN® and has the following main features:

•Application integration ready

•Easy add-on of the low-power LoRa® solution

•Extremely low CPU load

•No latency requirements

•Small STM32 memory footprint

•Low-power timing services

The firmware of the STM32CubeWL MCU Package is based on the STM32Cube HAL drivers.

This document provides customer application examples on the STM32WL Nucleo-64 boards NUCLEO_WL55JC (order codes NUCLEO WL55JC1 for high frequency band and NUCLEO-WL55JC2 for low-frequency band).

To fully benefit from the information in this application note and to create an application, the user must be familiar with the

STM32 microcontrollers, the LoRa® technology, and understand system services such as low-power management and task sequencing.

AN5406 - Rev 4 - February 2021	www.st.com
For further information contact your local STMicroelectronics sales office.

AN5406

Overview

1Overview

	The STM32CubeWL runs on STM32WL Series microcontrollers based on the Arm® Cortex®-M processor.
Note:	Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

1.1	Acronyms
		Table 1. Acronyms
	Acronym	Definition
	ABP	Activation by personalization
	ADR	Adaptive data rate
	BSP	Board support package
	HAL	Hardware abstraction layer
	LoRa	Long range radio technology
	LoRaWAN	LoRa wide-area network
	LPWAN	Low-power wide-area network
	MAC	Media access control
	MCPS	MAC common part sublayer
	MIB	MAC information base
	MLME	MAC sublayer management entity
	MSC	Message sequence chart
	<target>	STM32WL Nucleo-64 boards (NUCLEO-WL55JC)

1.2Reference documents

[1]User manual STM32 LoRa Expansion Package for STM32Cube (UM2073)

[2]STM32WLEx reference manual (RM0461)

[3]Application note LoRaWAN AT commands for STM32CubeWL (AN5481)

[4]Application note Building wireless applications with STM32WB Series microcontrollers (AN5289)

[5]IEEE Std 802.15.4TM - 2011. Low-Rate Wireless Personal Area Networks (LR-WPANs)

1.3LoRa standard

Refer to document [1] for more details on LoRa and LoRaWAN recommendations.

AN5406 - Rev 4	page 2/63

AN5406

STM32CubeWL architecture

2STM32CubeWL architecture

2.1STM32CubeWL overview

The firmware of the STM32CubeWL MCU Package includes the following resources (see Figure 1):

•Board support package: STM32WLxx_Nucleo drivers

•STM32WLxx_HAL_Driver

•Middleware:

–LoRaWAN containing:

◦LoRaWAN layer

◦LoRa utilities

◦LoRa software crypto engine

◦LoRa state machine

–SubGHz_Phy layer middleware containing the radio and radio_driver interfaces

•LoRaWAN applications:

–AT_Slave

–End_Node

•SubGHz_Phy application:

–PingPong

In addition, this application provides efficient system integration with the following:

•a sequencer to execute the tasks in background and enter low-power mode when there is no activity

•a timer server to provide virtual timers running on RTC (in Stop and Standby modes) to the application

For more details refer to Section 7 Utilities description.

AN5406 - Rev 4	page 3/63

AN5406

STM32CubeWL overview

Figure 1. Project file structure

BSP drivers for STM32WL Nucleo-64 board

STM32WL HAL drivers

Middleware LoRa crypto engine

Middleware LoRa state machine

Middleware LoRa MAC layer

Middleware LoRa utilities

Middleware SubGHz_Phy

LoRaWAN AT_Slave application

LoRaWAN End_Node application

SubGhz_Phy PingPong application

AN5406 - Rev 4	page 4/63

AN5406

Static LoRa architecture

2.2Static LoRa architecture

The figure below describes the main design of the firmware for the LoRa application.

Figure 2. Static LoRa architecture

LoRa application (AT_Slave, End_Node or PingPong)

LoRaWAN middleware
		LmHandler.h
LmHandler	LoRaMAC	LoRaMAC crypto	Utilities
		radio.h	Timer server
SubGHz_Phy middleware			Sequencer
	radio.c		Debug trace
	radio_driver.c		Low-power
			mode

Board support package (BSP)

Hardware abstraction layer APIs (HAL)

NVIC

SubGHz

RCC

GPIO

RTC

Sub-GHz radio system peripheral

The HAL uses STM32Cube APIs to drive the MCU hardware required by the application. Only specific hardware is included in the LoRa middleware as it is mandatory to run a LoRa application.

The RTC provides a centralized time unit that continues to run even in low-power mode (Stop 2 mode). The RTC alarm is used to wake up the system at specific timings managed by the timer server.

The radio driver uses the SubGHz HAL to control the radio (see the above figure). The radio driver also provides a set of APIs to be used by higher-level software.

The radio driver is split in the following parts:

•radio.c: contains all functions that are radio dependent only.

•radio_driver.c: contains low-level radio drivers.

The MAC controls the SubGHz_Phy using the 802.15.4 model. The MAC interfaces with the SubGHz_Phy driver and uses the timer server to add or remove timed tasks.

Since the state machine that controls the LoRa Class A, is sensitive, an intermediate level of software is inserted (lora.c) between the MAC and the application (refer to LoRaMAC driver in the above figure). With a limited set of APIs, the user is free to implement the Class A state machine at application level. For more details, refer to Section 6 .

The application, built around an infinite loop, manages the low-power, runs the interrupt handlers (alarm or GPIO) and calls the LoRa Class A if any task must be done.

AN5406 - Rev 4	page 5/63

AN5406

Dynamic view

2.3Dynamic view

The MSC (message sequence chart) shown in the figure below depicts a Class A device transmitting an application data and receiving application data from the server.

Figure 3. Class A Tx and Rx processing MSC

				CPU					Sub-GHz
									radio
LoRaApp		LmHandler		LoRaMAC		Radio		Timer	peripheral

	LmHandlerSend	LoRaMacMcps	RadioSend
		Request
	status	status	status
			Tx
	OnMacProcessNotify		RadioIsr
			OnRadioTxDone
	_LmHandler	LoRaMacProcess	setRxwindow1
	Packages
	Process
	OnTxdata	McpsConfirm	TimerIsr
			RadioRx
			Rx
	OnMacProcessNotify		RadioIsr
			OnRadioRxDone
	_LmHandler	LoRaMacProcess
	Packages
	Process
	OnRxdata	McpsIndication

Once the radio has completed the application data transmission, an asynchronous RadioIRQ wakes up the system. The RadioIsr here calls txDone in the handler mode.

All RadioIsr and MAC timer call a LoRaMacProcessNotify callback to request the application layer to update the LoRaMAC state and to do further processing when needed.

For instance, at the end of the reception, rxDone is called in the ISR (handler), but all the Rx packet processing including decryption must not be processed in the ISR. This case is an example of call sequence. If no data is received into the Rx1 window, then another Rx2 window is launched..

AN5406 - Rev 4	page 6/63

AN5406

SubGHz HAL driver

3SubGHz HAL driver

This section focuses on the SubGHz HAL (other HAL functions such as timers or GPIO are not detailed). The SubGHz HAL is directly on top of the sub-GHz radio peripheral (see Figure 2. Static LoRa architecture).

The SubGHz HAL driver is based on a simple one-shot command-oriented architecture (no complete processes). Therefore, no LL driver is defined.

This SubGHz HAL driver is composed the following main parts:

•Handle, initialization and configuration data structures

•Initialization APIs

•Configuration and control APIs

•MSP and events callbacks

•Bus I/O operation based on the SUBGHZ_SPI (Intrinsic services)

As the HAL APIs are mainly based on the bus services to send commands in one-shot operations, no functional state machine is used except the RESET/READY HAL states.

3.1SubGHz resources

The following HAL SubGHz APIs are called at the initialization of the radio:

•Declare a SUBGHZ_HandleTypeDef handle structure.

•Initialize the sub-GHz radio peripheral by calling the HAL_SUBGHZ_Init(&hUserSubghz) API.

•Initialize the SubGHz low-level resources by implementing the HAL_SUBGHZ_MspInit() API:

–PWR configuration: Enable wakeup signal of the sub-GHz radio peripheral.

–NVIC configuration:

◦Enable the NVIC radio IRQ interrupts.

◦Configure the sub-GHz radio interrupt priority.

The following HAL radio interrupt is called in the stm32wlxx_it.c file:

• HAL_SUBGHZ_IRQHandler in the SUBGHZ_Radio_IRQHandler.

3.2SubGHz data transfers

The Set command operation is performed in polling mode with the HAL_SUBGHZ_ExecSetCmd(); API. The Get Status operation is performed using polling mode with the HAL_SUBGHZ_ExecGetCmd(); API. The read/write register accesses are performed in polling mode with following APIs:

•HAL_SUBGHZ_WriteRegister();

•HAL_SUBGHZ_ReadRegister();

•HAL_SUBGHZ_WriteRegisters();

•HAL_SUBGHZ_ReadRegisters();

•HAL_SUBGHZ_WriteBuffer();

•HAL_SUBGHZ_ReadBuffer();

AN5406 - Rev 4	page 7/63

AN5406

BSP STM32WL Nucleo-64 boards

4BSP STM32WL Nucleo-64 boards

This BSP driver provides a set of functions to manage:

•an application dependent part, implementing external control of on-board components: RF switches, TCXO, RF losses and LEDs/sensors available on the STM32WL Nucleo-64 board (NUCLEO-WL55JC)

•a fixed part implementing the internal radio accesses (reset, busy and the NVIC radio IRQs)

Note:	In the current implementation, due to STM32CubeMX limitation, the firmware does not use BSP files but
	radio_board_if.c/.h for radio related items, and board_resources.c/.h for LED and push buttons. The
	choice between the two implementations is done into Core/Inc/platform.h by selecting USE_BSP_DRIVER
	or MX_BOARD_PSEUDODRIVER.

4.1 Frequency band

Two types of Nucleo board are available on the STM32WL Series:

• NUCLEO-WL55JC1: high-frequency band, tuned for frequency between 865 MHz and 930 MHz

• NUCLEO-WL55JC2: low-frequency band, tuned for frequency between 470 MHz and 520 MHz

Obviously, If the user tries to run a firmware compiled at 868 MHz on a low-frequency band board, very poor RF performances are expected.

The firmware does not check the band of the board on which it runs.

4.2	RF switch
	The STM32WL Nucleo-64 board embeds an RF 3-port switch (SP3T) to address, with the same board, the
	following modes:
	•	high-power transmission
	•	low-power transmission
	•	reception

Table 2. BSP radio switch

	Function	Description
	int32_t BSP_RADIO_Init(void)	Initializes the RF switch.
	BSP_RADIO_ConfigRFSwitch(BSP_RADIO_Switch_TypeDef Config)	Configures the radio switch.
	int32_t BSP_RADIO_DeInit (void)	De-initializes the RF switch.
	int32_t BSP_RADIO_GetTxConfig(void)	Returns the board configuration:
		high power, low power or both.
	The RF states versus the switch configuration are given in the table below.

Table 3. RF states versus switch configuration

RF state	FE_CTRL1	FE_CTRL2	FE_CTRL3
High-power transmission	Low	High	High
Low-power transmission	High	High	High
Reception	High	Low	High

AN5406 - Rev 4	page 8/63

AN5406

RF wakeup time

4.3RF wakeup time

The sub-GHz radio wakeup time is recovered with the following API.

Table 4. BSP radio wakeup time

Function	Description
uint32_t BSP_RADIO_GetWakeUpTime(void)	Returns RF_WAKEUP_TIME value.

The user must start the TCXO by setting the command RADIO_SET_TCXOMODE with a timeout depending of the application.

The timeout value can be updated in stm32wlxx_nucleo_conf.h. Default template value is defined below.

#define RF_WAKEUP_TIME

10U

4.4TCXO

Various oscillator types can be mounted on the user application. On the STM32WL Nucleo-64 boards, a TCXO (temperature compensated crystal oscillator) is used to achieve a better frequency accuracy.

Table 5. BSP radio TCXO

Function	Description
uint32_t BSP_RADIO_IsTCXO (void)	Returns IS_TCXO_SUPPORTED value.

The user can change this value in stm32wlxx_nucleo_conf.h:

#define IS_TCXO_SUPPORTED

1U

4.5Power regulation

Depending on the user application, a LDO or an SMPS (also named DCDC) is used for power regulation. An SMPS is used on the STM32WL Nucleo-64 boards.

Table 6. BSP radio SMPS

Function	Description
uint32_t BSP_RADIO_IsDCDC (void)	Returns IS_DCDC_SUPPORTED value.

The user can change this value in stm32wlxx_nucleo_conf.h:

#define IS_DCDC_SUPPORTED

1U

The SMPS on the board can be disabled by setting IS_DCDC_SUPPORTED to 0.

AN5406 - Rev 4	page 9/63

AN5406

STM32WL Nucleo-64 board schematic

4.6STM32WL Nucleo-64 board schematic

The figure below details the STM32WL Nucleo-64 board, MB1389 reference board schematic, highlighting some useful signals:

•control switches on PC4, PC5 and PC3

•TCXO control voltage PIN on PB0

•debug lines on PB12, PB13 and PB14

•system clock on PA8

•SCK on PA5

•MISO on PA6

•MOSI on PA7

Figure 4. NUCLEO-WL55JC schematic

Data transaction:

SKC, MOSI, MISO

Control switchs 1 and 2

System clock

TCXO control voltage

Control switch 3

Debug line 2 and 3	Debug line 1

AN5406 - Rev 4	page 10/63

AN5406

SubGHz_Phy layer middleware description

5SubGHz_Phy layer middleware description

The radio abstraction layer is composed of two layers:

•high-level layer (radio.c)

It provides a high-level radio interface to the stack middleware. It also maintains radio states, processes interrupts and manages timeouts. It records callbacks and calls them when radio events occur.

•low-level radio drivers

It is an abstraction layer to the RF interface. This layer knows about the register name and structure, as well as detailed sequence. It is not aware about hardware interface.

The SubGHz_Phy layer middleware contains the radio abstraction layer that interfaces directly on top of the hardware interface provided by BSP (refer Section 4 BSP STM32WL Nucleo-64 boards).

The SubGHz_Phy middleware directory is divided in two parts

•radio.c: contains a set of all radio generic callbacks, calling radio_driver functions. This set of APIs is meant to be generic and identical for all radios.

•radio_driver.c: low-level radio drivers

AN5406 - Rev 4	page 11/63

AN5406

Middleware radio driver structure

5.1Middleware radio driver structure

A radio generic structure, struct Radio_s Radio {};, is defined to register all the callbacks, with the fields detailed in the table below.

	Table 7. Radio_s structure callbacks
Callback	Description
RadioInit	Initializes the radio.
RadioGetStatus	Returns the current radio status.
RadioSetModem	Configures the radio with the given modem.
RadioSetChannel	Sets the channel frequency.
RadioIsChannelFree	Checks if the channel is free for the given time.
RadioRandom	Generates a 32-bit random value based on the RSSI readings.
RadioSetRxConfig	Sets the reception parameters.
RadioSetTxConfig	Sets the transmission parameters.
RadioCheckRfFrequenc	Checks if the given RF frequency is supported by the hardware.
RadioTimeOnAir	Computes the packet time on air in ms, for the given payload.
RadioSend	Sends the buffer of size. Prepares the packet to be sent and sets the radio in
	transmission.
RadioSleep	Sets the radio in Sleep mode.
RadioStandby	Sets the radio in Standby mode.
RadioRx	Sets the radio in reception mode for the given time.
RadioStartCad	Starts a CAD (channel activity detection).
RadioSetTxContinuousWave	Sets the radio in continuous wave transmission mode.
RadioRssi	Reads the current RSSI value.
RadioWrite	Writes the radio register at the specified address.
RadioRead	Reads the radio register at the specified address.
RadioSetMaxPayloadLength	Sets the maximum payload length.
RadioSetPublicNetwork	Sets the network to public or private. Updates the sync byte.
RadioGetWakeUpTime	Gets the time required for the board plus radio to exit Sleep mode.
RadioIrqProcess	Processes radio IRQ.
RadioRxBoosted	Sets the radio in reception mode with max LNA gain for the given time.
RadioSetRxDutyCycle	Sets the Rx duty-cycle management parameters.
RadioTxPrbs	Sets the transmitter in continuous PRBS mode.
RadioTxCw	Sets the transmitter in continuous unmodulated carrier mode.

AN5406 - Rev 4	page 12/63

AN5406

Radio IRQ interrupts

5.2Radio IRQ interrupts

The possible sub-GHz radio interrupt sources are detailed in the table below.

Table 8. Radio IRQ bit mapping and definition

Bit	Source	Description	Packet type	Operation
0	txDone	Packet transmission finished		Tx
1	rxDone	Packet reception finished	LoRa and GFSK
2	PreambleDetected	Preamble detected
3	SyncDetected	Synchronization word valid	GFSK
4	HeaderValid	Header valid	LoRa	Rx
5	HeaderErr	Header error
	Err	Preamble, sync word, address, CRC or	GFSK
6		length error
	CrcErr	CRC error
7	CadDone	Channel activity detection finished	LoRa	CAD
8	CadDetected	Channel activity detected
9	Timeout	Rx or TX timeout	LoRa and GFSK	Rx and Tx

For more details, refer to the product reference manual.

AN5406 - Rev 4	page 13/63

AN5406

LoRaWAN middleware description

6LoRaWAN middleware description

The LoRa stack middleware is split into the following modules:

•LoRaMAC layer module (in Middlewares\Third_Party\LoRaWAN\Mac)

•LoRa utilities module (in Middlewares\Third_Party\LoRaWAN\Utilities)

•LoRa crypto module (in Middlewares\Third_Party\LoRaWAN\Crypto)

•LoRa LmHandler module (in Middlewares\Third_Party\LoRaWAN\LmHandler)

6.1LoRaWAN middleware features

•Compliant with the specification for the LoRa Alliance protocol, named LoRaWAN

•On-board LoRaWAN Class A, Class B and Class C protocol stack

•EU 868MHz ISM band ETSI compliant

•EU 433MHz ISM band ETSI compliant

•US 915MHz ISM band FCC compliant

•KR 920Mhz ISM band defined by Korean government

•RU 864Mhz ISM band defined by Russian regulation

•CN 779Mhz and CN470Mhz ISM bands defined by Chinese government

•AS 923Mhz ISM band defined by Asian governments

•AU 915Mhz ISM bands defined by Australian government

•IN 865Mhz ISM bands defined by Indian government

•End-device activation either through OTAA or through activation-by-personalization (ABP)

•Adaptive data rate support

•LoRaWAN test application for certification tests included

•Low-power optimized

6.2LoRaWAN middleware initialization

The initialization of the LoRaMAC layer is done through the LoRaMacInitialization API, that initializes both the preamble run time of the LoRaMAC layer and the callback primitives of the MCPS and MLME services (see the table below).

Table 9. LoRaWAN middleware initialization

Function	Description

LoRaMacStatus_t LoRaMacInitialization
(LoRAMacPrimitives_t *primitives,	Initializes the LoRaMAc layer module
LoRaMacCallback_t *callback,	(see Section 6.4 Middleware MAC layer callbacks)
LoRaMacRegion_t region)

6.3Middleware MAC layer APIs

The provided APIs follow the definition of “primitive” defined in IEEE802.15.4-2011 (see document [5]).

The interfacing with the LoRaMAC is made through the request-confirm and the indication-response architecture. The application layer can perform a request that the LoRaMAC layer confirms with a confirm primitive. Conversely, the LoRaMAC layer notifies an application layer with the indication primitive in case of any event.

The application layer may respond to an indication with the response primitive. Therefore, all the confirm or indication are implemented using callbacks.

AN5406 - Rev 4	page 14/63

AN5406

Middleware MAC layer APIs

The LoRaMAC layer provides the following services:

•MCPS services

In general, the LoRaMAC layer uses the MCPS services for data transmissions and data receptions.

	Table 10. MCPS services
	Function	Description
	LoRaMacStatus_t LoRaMacMcpsRequest	Requests to send Tx data.
	(McpsReq_t *mcpsRequest)

•MLME services

The LoRaMAC layer uses the MLME services to manage the LoRaWAN network.

	Table 11. MMLE services
	Function	Description
	LoRaMacStatus_t LoRaMacMlmeRequest	Generates a join request or requests for a link check.
	(MlmeReq_t *mlmeRequest )

•MIB services

The MIB stores important runtime information (such as MIB_NETWORK_ACTIVATION or MIB_NET_ID) and holds the configuration of the LoRaMAC layer (for example the MIB_ADR, MIB_APP_KEY).

Table 12. MIB services

Function	Description

	LoRaMacStatus_t LoRaMacMibSetRequestConfirm	Sets attributes of the LoRaMAC layer.
	(MibRequestConfirm_t *mibSet)
	LoRaMacStatus_t LoRaMacMibGetRequestConfirm	Gets attributes of the LoRaMAC layer.
	(MibRequestConfirm_t *mibGet )

AN5406 - Rev 4	page 15/63

AN5406

Middleware MAC layer callbacks

6.4Middleware MAC layer callbacks

The LoRaMAC user event functions primitives (also named callbacks) to be implemented by the application are the following:

•MCPS

		Table 13. MCPS primitives
	Function		Description
	void (*MacMcpsConfirm )		Response to a McpsRequest
	(McpsConfirm_t *McpsConfirm)
	Void (*MacMcpsIndication)		Notifies the application that a received packet is available.
	(McpsIndication_t *McpsIndication)

•	MLME
		Table 14. MLME primitive
	Function		Description
	void ( *MacMlmeConfirm )		Manages the LoRaWAN network.
	( MlmeConfirm_t *MlmeConfirm )

•MIB

No available functions.

6.5Middleware MAC layer timers

•Delay Rx window

Refer to document [1], section 'End-device classes' for more details.

Table 15. Delay Rx window

	Function	Description
void	OnRxWindow1TimerEvent (void)	Sets the RxDelay1
		(ReceiveDelayX - RADIO_WAKEUP_TIME).
void	OnRxWindow2TimerEvent (void)	Sets the RxDelay2.

•Delay for Tx frame transmission

Table 16. Delay for Tx frame transmission

Function	Description
void OnTxDelayedTimerEvent (void)	Sets the timer for Tx frame transmission.

AN5406 - Rev 4	page 16/63

AN5406

Middleware LmHandler application function

•Delay for Rx frame

Table 17. Delay for Rx frame

Function	Description
void OnAckTimeoutTimerEvent (void)	Sets timeout for received frame acknowledgment.

6.6Middleware LmHandler application function

The interface to the MAC is done through the MAC interface LoRaMac.h file, in one of the following modes:

•Standard mode

An interface file (LoRaMAC driver, see Figure 2 ) is provided to let the user start without worrying about the LoRa state machine. This file is located in

Middlewares\Third_Party\LoRaWAN\LmHandler\LmHandler.c and implements:

–a set of APIs to access to the LoRaMAC services

–the LoRa certification test cases that are not visible to the application layer

•Advanced mode

The user accesses directly the MAC layer by including the MAC in the user file.

AN5406 - Rev 4	page 17/63

AN5406

Middleware LmHandler application function

6.6.1Operation model

The operation model proposed for the LoRa End_Node is based on ‘event-driven’ paradigms including ‘timedriven’ (see the figure below). The behavior of the LoRa system is triggered either by a timer event or by a radio event plus a guard transition.

Figure 5. Operation model

The next sections detail the End_Node and AT_Slave APIs used to access the LoRaMAC services. The corresponding interface files are located in:

Middlewares\Third_Party\LoRaWAN\LmHandler\LmHandler.c

The user must implement the application with these APIs. An example of End_Node application is provided in

\Projects\<target>\Applications\LoRaWAN\End_Node\LoRaWAN\App\lora_app.c. An example of AT_Slave application is provided in

\Projects\<target>\Applications\LoRaWAN\AT_Slave\LoRaWAN\App\lora_app.c.

AN5406 - Rev 4	page 18/63

			AN5406
			Middleware LmHandler application function
6.6.2	Main application functions definition
	Table 18. LoRa initialization
	Function		Description
	LmHandlerErrorStatus_t LmHandlerInit		Initialization of the LoRa finite state machine
	(LmHandlerCallbacks_t *handlerCallbacks)
	Table 19. LoRa configuration
	Function		Description
	LmHandlerErrorStatus_t LmHandlerConfigure		Configuration of all applicative parameters
	(LmHandlerParams_t *handlerParams)
	Table 20. LoRa End_Node join request entry point
	Function		Description
	void LmHandlerJoin (ActivationType_t mode)		Join request to a network either in OTAA mode or
			ABP mode.
	Table 21. LoRa stop
	Function		Description
	void LmHandlerStop (void)	Stops the LoRa process and waits a new configuration
		before a rejoin action.
	Table 22. LoRa request class
	Function		Description
	LmHandlerErrorStatus LmHandlerRequestClass		Requests the MAC layer to change LoRaWAN
	(DeviceClass_t newClass)		class.
	Table 23. Send an uplink frame
	Function		Description
	LmHandlerErrorStatus_t LmHandlerSend		Sends an uplink frame. This frame can be either
	(LmHandlerAppData_t *appData,
	LmHandlerMsgTypes_t isTxConfirmed)		an unconfirmed empty frame or an unconfirmed/
			confirmed payload frame.

TimerTime_t *nextTxIn, bool allowDelayedTx)

AN5406 - Rev 4	page 19/63