Doc43081 G3-PLC Firmware Stack User Guide
Doc43081 G3-PLC Firmware Stack User Guide
USER GUIDE
Introduction
This document is the user guide for the Atmel G3-PLC firmware stack.
The mechanisms and functionality of the G3-PLC specification is the basis of the
entire firmware stack implementation. Therefore, it is highly recommended to use
it as a reference. Basic concepts that are introduced by this G3-PLC specification
are assumed to be known within this document.
Features
Atmel-43081W-ATPL-G3-PLC_Firmware_Stack-User Guide_6-Apr-17
Table of Contents
1 General architecture .................................................................................................... 9
1.1 PHY Layer ........................................................................................................................................... 10
1.2 Physical Abstraction Layer (PAL) ........................................................................................................ 10
1.3 MAC Layer (IEEE 802.15.4) ................................................................................................................ 11
1.4 ADP Layer (IETF RFC 4944) .............................................................................................................. 11
1.5 Serialization Layers. Universal Serial Interface (USI) .......................................................................... 13
1.6 Hardware Abstraction Layer (HAL)...................................................................................................... 13
1.7 User Application .................................................................................................................................. 13
10 Abbreviations............................................................................................................. 40
11 References ................................................................................................................. 41
12 Evaluation License Agreement ................................................................................. 42
13 Revision History ........................................................................................................ 44
Appendix A API of PHY and PAL Layers ..................................................................... 45
A.1 PHY SAP ............................................................................................................................................. 45
A.1.1 Initialization function ............................................................................................................... 45
A.1.2 Event Handler function ........................................................................................................... 45
A.1.3 Phy Data Primitives ................................................................................................................ 45
A.1.4 Configuring PHY layer parameters ......................................................................................... 50
A.1.5 Phy Management Primitives ................................................................................................... 52
A.2 PAL SAP ............................................................................................................................................. 53
A.2.1 Initialization function ............................................................................................................... 53
A.2.2 Event handler function ............................................................................................................ 53
A.3 PAL Primitives ..................................................................................................................................... 53
A.3.1 Data Primitives ....................................................................................................................... 53
A.3.2 Management Primitives .......................................................................................................... 53
app_if
USER APPLICATION
G3-PLC Stack
Embedded USI
Adaptation adp_if
SAM4C
Layer
HAL
MAC mac_if
Layer (IEEE 802.15.4)
PAL
Layer (ITU-T G.9903)
phy_if
PHY Layer sniffer_if
SPI
G3-PLC Transceiver
ATPL250A
ATPL360A
PLC
app_if
USER APPLICATION
G3-PLC Stack
Embedded USI
SAM4CP16C
Adaptation adp_if
Layer (IETF RFC 4944)
HAL
MAC mac_if
Layer (IEEE 802.15.4)
PAL
Layer (ITU-T G.9903)
phy_if
PHY Layer sniffer_if
GPLC
PLC
Note that the provided Platform source code is only an implementation example. Users should modify the code
according to their hardware and specifications.
There are different groups of functions, e.g. to initialize HW, write parameters in flash, power down detection,
timer interrupt management, etc.
/* OS Support */
#define OSS_USE_FREERTOS
For configuring the FW stack to operate in RTOS mode please define OSS_USE_FREERTOS.
If OSS_USE_FREERTOS is not defined then the FW is executed in microcontroller operation
mode. (See chapter 4.4.8 OSS Layer configuration – conf_oss.h)
Please note that the default RTOS included in the stack is FreeRTOS.
Also note that the RTOS mode is provided as an example of integration of the stack inside an
OS with demonstration purposes only. It should not be taken as the starting point of a
development, and Atmel does not ensure the same performance and stability as the examples
running in microcontroller mode.
This compilation constant changes the way code is executed in file oss_if.c, which is the file in charge of
controlling the program flow. This file contains all the calls to initialization functions, calls to time control functions
and calls to periodic task handler functions. All this is done in a different way depending on the operation mode,
but the idea of controlling the program flow from this file is the same.
Regardless of the approach, user has to ensure that the G3 periodic task is called every 1ms
with the highest priority, no other user task should interrupt the G3 task execution. This
ensures that time restrictions defined by G3 spec are met.
/* Configure OSS_IF */
oss_set_app_init(short_cycle_base_init);
oss_set_app_process(process_cycles_app);
oss_set_1ms_timer_cb(update_cycles_timer);
/* Start OSS */
oss_start();
}
Three clear tasks can be seen here:
Initialization.
Set User App function pointers.
Start execution.
Let’s take a closer look at these 3 steps.
/* Initialize eui64 */
platform_init_eui64(CONF_EXTENDED_ADDRESS);
#ifdef OSS_ENABLE_IPv6_STACK_SUPPORT
/* Initialize IPv6 stack */
netInit();
#endif
/* User-defined initialization */
if(pf_app_init_cb != NULL) {
pf_app_init_cb();
}
#if (NUM_PORTS != 0)
usi_init();
#endif
/* main loop */
while (1) {
/* Reset watchdog */
RESET_WATCHDOG
if (platform_flag_call_process()) {
/* User-defined initialization */
if(pf_app_process_cb != NULL) {
pf_app_process_cb();
}
#if (NUM_PORTS != 0)
usi_process();
#endif
/* G3 stack process */
#ifdef OSS_G3_ADP_MAC_SUPPORT
AdpEventHandler(); /* Internally calls MAC and
PHY Event handlers */
#endif
/* LED blink */
platform_led_update();
}
}
This function perform some interesting tasks which will be explained in the next subsections.
4.2.3.1 Time Control initialization
/* Set up timer interrupt and user defined callback */
platform_set_ms_callback(&_oss_1ms_timer_handler);
platform_init_1ms_timer();
platform_led_cfg_blink_rate(OSS_LED_BLINK_RATE);
platform_cfg_call_process_rate(OSS_APP_EXEC_RATE);
First of all, mechanisms for time control are initialized. A callback function defined in oss_if.c file is configured to
be called every time that a HW interrupt raises (this HW interrupt is defined and handled in platform.c file), using
function platform_set_ms_callback. Then the HW interrupt itself is configured and enabled using function
platform_init_1ms_timer.
This way, we have a function in OSS that is called every 1ms, independently of the platform below (platform
functions have to be correctly implemented to ensure this). Such function will be in charge of managing the time
base for the G3 stack.
Next function, platform_led_cfg_blink_rate, configures the rate at which an activity led blinks in the board
periodically, just to indicate that program is running, the rate is defined by the constant OSS_LED_BLINK_RATE,
located in file conf_oss.h, and its value is indicated in milliseconds. This is an auxiliary function which does not
affect at all to G3 stack functionality.
Finally, function platform_cfg_call_process_rate is used to define the rate at which the user application and G3
stack event handlers are called. It is defined using the constant OSS_APP_EXEC_RATE located in file oss_if.h.
The reason this constant is not located in a configuration file is that this rate should not be changed by the user.
User can check the value of this constant in order to know the rate at which the periodic function defined to be
called in application (as seen in section 4.2.2 Second step. Setting user function pointers) will be called, but the
value should remain unchanged.
4.2.3.2 Power down detection
#ifdef PLATFORM_ENABLE_POWER_DOWN_DETECTION /* Power down detection
initialization */
platform_init_power_down_det();
#endif
G3 stack needs that some information is stored in non-volatile memory so it can be restored after a power down.
In order to do so, the stack keeps that information updated in a dedicated structure, but needs to know when it
is necessary to save it to non-volatile memory. For this purpose, a power down detection mechanism is
implemented in platform files. I user wants to use this power down detector, constant
PLATFORM_ENABLE_POWER_DOWN_DETECTION has to be defined, it is located in conf_platform.h file.
When this is defined, all needed hardware is initialized using function platform_init_power_down_det.
As everything in platform files, provided implementation is valid when using Atmel development boards. In case
user develops its own board, this implementation may have to be changed.
4.2.3.3 EUI64 initialization
/* Initialize eui64 */
platform_init_eui64(CONF_EXTENDED_ADDRESS);
Every device in a G3 network needs a unique EUI64 to be identified.
Figure 4-7. ADP Data Request flow chart. Retransmission due to ACK fail.
Figure 4-9. ADP GET Request and ADP SET Request flow charts.
The ADPM-MAC.GET.request primitive allows the upper layer to get the value of an attribute from the MAC
information base. The upper layer cannot access directly the MAC layer while ADP is running. The ADPM-
MAC.GET.confirm primitive allows the upper layer to be informed of the status of a previously issued ADPM-
MAC.GET.request primitive.
The ADPM-MAC.SET.request primitive allows the upper layer to set the value of an attribute in the MAC
information base. The upper layer cannot access directly the MAC layer while ADP is running. The ADPM-
MAC.SET.confirm primitive allows the upper layer to be informed about a previous ADPM-MAC.SET.request
primitive.
Please take into account the requirements, handling and usage of the Atmel G3-PLC FW
Stack prior to changing the RTOS configuration. Please read carefully chapter 5 Operating
System Support.
G3-PLC FW Stack does not manage this save/restore mechanism itself. It is up to Application
to manage this storage and recovery of the required data.
The data that needs to be persistently stored is the one contained in the following ADP and MAC IBs:
MAC_PIB_FRAME_COUNTER
ADP_IB_MANUF_DISCOVER_SEQUENCE_NUMBER
ADP_IB_MANUF_BROADCAST_SEQUENCE_NUMBER
Application has to make sure that these IBs are read before the reset / power down occurs, and that the same
IBs are written with the previously read values just after G3 stack initialization.
In the provided Example Application DLMS Emulator (see 7.1.1), the user can find an implementation of this
mechanism, using a provided module called “Storage”.
To summarize what the example does, it stores the read values on GPBRs when some of them change, so the
values can be restored after a reset, and at the same time, it uses a functionality of the “Platform” module which
is able to detect an imminent Power down, in which case, the information is stored in non-volatile memory to be
restored at the next power up.
5.1 Overview
User applications can run over an operating system, which means that the G3-PLC stack implementation needs
to support that.
The OSS intends to transform the microcontroller-mode operation into a task-mode operation typical of operating
systems. In order to do that, it creates and manages a single task where all active layers and interfaces are
included. The user does not need to take care of controlling how the G3-PLC stack is running and can create
their applications normally. The current implementation of the OSS is based on FreeRTOS but the user can
modify it appropriately to use any other RTOS.
5.2 G3-PLC process. Requirements, Handling and Usage of the G3-PLC FW stack
When RTOS is used, the user has to take into account the requirements of different tasks running, to configure
parameters such as the stack for each one of the tasks.
The implementation given takes into account the needed resources for provided example, but any modification
may have a direct impact on these needs, and thus FreeRTOS configuration file may need to be modified.
Please take into account that the provided RTOS support is just an example of integration of
the stack in an RTOS. It is functional, but Atmel does not ensure the same reliability and
performance as the microcontroller mode implementation, as the latter is the reference
implementation.
Along with the G3-PLC FW stack, some application examples are provided in order to show how to use the stack.
Examples can be divided in 2 groups:
ADP examples, using the whole stack (ADP + MAC + PHY), to evaluate Atmel’s G3 solution as a whole.
PHY examples, using only PHY layer, in order to evaluate some low level parameters, or to be used
connected to a PC tool for demonstration purposes.
Both groups are detailed below.
Applications are provided for Cenelec, FCC and ARIB bands (project folders with suffixes “_cen” and “_fcc_arib”
in each example shall be used). Setting FCC or ARIB band in common projects is made by means of
conf_project.h file, as explained in section 4.4.11.
7.2.3 TX console
Due to PC timing, the Atmel PLC PHY Tester Tool may present limitations in those applications or tests that
require a very short time interval between consecutives frame transmissions. The PHY Test Console example
has been developed for those applications.
The PHY Test Console is an application example that demonstrates the complete performance of the Atmel G3
PHY Layer avoiding the limitations of timing in the PC host. Then, users can perform more specific PHY tests
(e.g. short time interval between consecutive frames).
This PHY Test Console application offers an interface to the user by means a command console. In this console,
users can configure several transmission parameters, such as modulation, frame data length and time interval
between frames. In the console it is also possible to test transmission/reception processes.
This example offers the serial interface configured through UART1 at 115200bps.
APP Application
FW Firmware
TRX Transceiver
General revision of document. Chapter 4 deeply reviewed to show the stack functionality
doc43081I 09/2015 following one of the provided examples. Removed USI chapter. Added package
directory structure to complete chapter 2.
doc43081J 11/2015 Added new MAC and ADP IBs. Changed ZC_Delay figure for better understanding.
doc43081K 11/2015 Added new MAC and ADP IBs.
doc43081L 02/2016 Added Appendix C – LBP module.
Added new MAC and ADP IBs. Unique frame counter affects
doc43081M 03/2016
MAC_PIB_FRAME_COUNTER and MAC_PIB_MANUF_DEVICE_TABLE definitions.
doc43081N 04/2016 Added new ADP API function AdpPREQIndication. Watermark removed.
Review Appendix A. Review and completed LBP Objects Specification and Access
(Appendix C) to clarify access type and sizes of objects. Added status codes in Get/Set
doc43081O 04/2016 functions. Added Persistent Data Storage chapter (4.5). Completed information of setup
dependent parameters in DLMS Emulator example chapter. Added documentation for
new ADP_IB_MANUF_KEEP_PARAMS_AFTER_KICK_LEAVE.
doc43081P 06/2016 Completed Appendix C with a brief explanation of provided LBP module.
Added new PHY Params available as MAC MIB. Added MAC and ADP MIBs. Added
doc43081Q 07/2016 new ADP Primitive to indicate when non-volatile parameters change. Added support to
SAME70 and to Keil Compiler.
doc43081R 09/2016 Removed references to old names of functions and PIBs.
Added section B.8 ADP Status Codes description. Available impedance parameters
doc43081S 09/2016
documented. Format changes after document revision.
doc43081T 12/2016 Added ADP_IB_MANUF_MAX_REPAIR_RESEND_ATTEMPTS.
doc43081U 01/2017 Added new ADP IBs description and new ADP API primitive.
Params:
uint8_t phy_process(void);
uint8_t m_uc_buff_id;
uint8_t m_uc_tx_mode;
uint8_t m_uc_pdc;
uint8_t m_auc_tone_map[TONE_MAP_SIZE];
uint8_t m_uc_2_rs_blocks;
uint8_t m_auc_preemphasis[NUM_SUBBANDS];
uint8_t *m_puc_data_buf;
uint16_t m_us_data_len;
uint32_t m_ul_tx_time;
} xPhyMsgTx_t;
m_uc_tx_mode Transmission Mode (forced, delayed, ...) (Related Constants explained below)
m_uc_tx_power Power to transmit [0 = Full gain, 1 = (Full gain - 3dB), 2 = (Full gain - 6dB) and so
on]
m_uc_pdc Phase Detector Counter. Calculated and filled internally by PHY layer
uc_2_rs_blocks Flag to indicate whether 2 RS blocks have to be used (only used in FCC
bandplan)
m_auc_preemphasis Preemphasis for transmission. Same as m_uc_tx_power but for each subband
(Related Constants explained below)
m_ul_tx_time Instant when transmission has to start referred to 1us PHY counter (Absolute
value, not relative). Only used when m_uc_tx_mode is Delayed transmission
/* Modulation types */
enum mod_types {
MOD_TYPE_BPSK = 0,
MOD_TYPE_QPSK = 1,
MOD_TYPE_8PSK = 2,
MOD_TYPE_QAM = 3,
MOD_TYPE_BPSK_ROBO = 4
};
/* Modulation schemes */
enum mod_schemes {
MOD_SCHEME_DIFFERENTIAL = 0,
MOD_SCHEME_COHERENT = 1
};
#if defined(CONF_CENELEC_A)
#define TONE_MAP_SIZE TONE_MAP_SIZE_CENELEC
#else
#define TONE_MAP_SIZE TONE_MAP_SIZE_FCC_ARIB
#endif
A.1.3.2 PHY-DATA.confirm
This data confirm callback executes the function set by the upper layer at the initialization of the PAL layer (See
A.2.1). The pointer to the function is set in
uint8_t m_uc_id_buffer;
uint32_t m_ul_rms_calc;
uint32_t m_ul_end_tx_time;
} xPhyMsgTxResult_t;
m_ul_end_tx_time Instant when frame transmission ended referred to 1us PHY counter
uint8_t m_uc_buff_id;
uint8_t m_auc_tone_map[TONE_MAP_SIZE];
uint16_t m_us_evm_header;
uint16_t m_us_evm_payload;
uint16_t m_us_rssi;
uint16_t m_us_agc_factor;
uint8_t m_uc_zct_diff;
uint8_t m_uc_rs_corrected_errors;
uint8_t *m_puc_data_buf;
uint16_t m_us_data_len;
uint32_t m_ul_rx_time;
uint32_t m_ul_frame_duration;
} xPhyMsgRx_t;
e_mod_type Modulation type of the last received frame. Related Constants defined in
section A.1.3.1
e_mod_scheme Modulation scheme of the last received frame. Related Constants defined
in section A.1.3.1
m_auc_tone_map Tone Map in received frame. Related Constants defined in section A.1.3.1
m_ul_rx_time Instant when frame was received (end of frame) referred to 1us PHY
counter
#define CONF_CENELEC_A
#define CONF_FCC
#define CONF_ARIB
#else /* Default */
#define CONF_CENELEC_A
#endif
One of the 3 constants CONF_BAND_XXX has to be defined in order to PHY layer is correctly configured.
In the provided examples, this definition can be found in file conf_project.h.
A.1.4.2 ZC offset configuration
PHY layer calculates the electrical phase difference between transmitter and receiver for a given frame. To do
so, both devices have to be able to read the Zero Cross time of the mains.
The structure used as input of phy_set_callbacks function contains two fields which are pointers to the functions
to be executed after a PLC transmission or reception:
The function returns 0 if there is no error, otherwise returns Error Type (see atpl250.h).
A.1.5.2 PHY_GET.request
The function returns 0 if there is no error, otherwise returns Error Type (see atpl250.h).
A.1.5.3 PHY_RESET.request
It is possible to force a reset of PHY layer during program execution, calling the function:
This function performs the setting of the PHY callbacks and initializes the PHY layer.
void PalEventHandler(void);
Parameters:
*pNotifications Structure with callbacks used to notify MAC specific events (if NULL the layer is
deinitialized)
u8Band Frequency band. This has to match the hardware. Use one of the constants:
BAND_CENELEC_A
BAND_CENELEC_B
BAND_FCC
BAND_ARIB.
void MacEventHandler(void)
struct TMacSecurityKey
bool m_bValid;
};
struct TNeighbourEntry {
uint8_t m_nModulationType : 3;
uint8_t m_nTxGain : 4;
uint8_t m_nTxRes : 1;
uint8_t m_nModulationScheme : 1;
uint8_t m_nPhaseDifferential : 3;
uint8_t m_u8Lqi;
Carrier 58
Carrier 57
Carrier 56
Carrier 55
Not Used
Not Used
Not Used
Not Used
Not Used
Not Used
Not Used
Not Used
…
…
Access: R/W.
Value Range: 0x00-0xFF for each of 9 bytes.
Default Value: All bytes set to 0xFF (All carriers are enabled).
struct TBandInformation {
uint8_t m_u8Band;
uint8_t m_u8Tones;
uint8_t m_u8Carriers;
uint8_t m_u8TonesInCarrier;
uint8_t m_u8FlBand;
uint16_t m_u16FlMax;
uint8_t m_u8MaxRsBlocks;
uint8_t m_u8TxCoefBits;
};
1 byte – band
1 byte – number of tones
1 byte – number of carriers
1 byte – tones in a carrier
1 byte – FLBand
1 byte – reserved
2 byte – FLmax
1 byte – maximal number of RS blocks
1 byte – number of bits in one entry of the TXCOEF table
Access: Read-only.
struct TPhyToneMap {
uint8_t m_au8Tm[3];
};
A value of “all zeros” means Tone Map is not forced and Neighbour Table info will be used.
Default value: [0x00, 0x00, 0x00].
Note: For Cenelec Band only first element of the array is used, as Tone Map length is 6 bits.
struct TPhyToneMap {
uint8_t m_au8Tm[3];
};
A value of “all zeros” means Tone Map field is not forced and internal G3 stack info will be used.
Default value: [0x00, 0x00, 0x00].
Note: For Cenelec Band only first element of the array is used, as Tone Map length is 6 bits.
Parameters:
pNotifications Structure with callbacks used to notify ADP specific events (if NULL the layer is
deinitialized)
struct TAdpNotifications {
AdpDataConfirm fnctAdpDataConfirm;
AdpDataIndication fnctAdpDataIndication;
AdpDiscoveryConfirm fnctAdpDiscoveryConfirm;
AdpDiscoveryIndication fnctAdpDiscoveryIndication;
AdpNetworkStartConfirm fnctAdpNetworkStartConfirm;
AdpNetworkJoinConfirm fnctAdpNetworkJoinConfirm;
AdpNetworkLeaveIndication fnctAdpNetworkLeaveIndication;
AdpNetworkLeaveConfirm fnctAdpNetworkLeaveConfirm;
AdpResetConfirm fnctAdpResetConfirm;
AdpSetConfirm fnctAdpSetConfirm;
AdpMacSetConfirm fnctAdpMacSetConfirm;
AdpGetConfirm fnctAdpGetConfirm;
AdpMacGetConfirm fnctAdpMacGetConfirm;
AdpLbpConfirm fnctAdpLbpConfirm;
AdpLbpIndication fnctAdpLbpIndication;
AdpRouteDiscoveryConfirm fnctAdpRouteDiscoveryConfirm;
AdpPathDiscoveryConfirm fnctAdpPathDiscoveryConfirm;
AdpNetworkStatusIndication fnctAdpNetworkStatusIndication;
AdpPREQIndication fnctAdpPREQIndication;
AdpUpdNonVolatileDataIndication fnctAdpUpdNonVolatileDataIndication;
AdpBrokenRouteIndication fnctAdpBrokenRouteIndication;
};
enum TAdpBand {
};
bool AdpEventHandler(void);
B.5.1 ADPD-DATA.request
The ADPD-DATA.request primitive requests the transfer of an application PDU (i.e.: IPv6 packet) to another
device or multiple devices.
Parameters:
u8NsduHandle The handle of the NSDU to transmit. This parameter is used to identify in the
AdpDataConfirm primitive which request it is concerned with. It can be randomly
chosen by the application layer.
bDiscoverRoute If TRUE, a route discovery procedure will be performed prior to sending the frame
if a route to the destination is not available in the routing table. If FALSE, no route
discovery is performed.
u8QualityOfService The requested quality of service (QoS) of the frame to send. Allowed values are:
[0x00 = normal priority; 0x01 = high priority].
When the execution of the DataRequest is finished the callback AdpDataConfirm is called to inform the user
about the status of the operation.
struct TAdpDataConfirm {
uint8_t m_u8Status;
uint8_t m_u8NsduHandle;
};
B.5.3 ADPD-DATA.indication
The ADPD-DATA.indication primitive is used to transfer received data from the adaptation sublayer to the upper
layer.
When user data is received by the modem, the callback AdpDataIndication is called:
struct TAdpDataIndication {
uint16_t m_u16NsduLength;
uint8_t m_u8LinkQualityIndicator;
};
m_u8LinkQualityIndicator The value of the link quality during the receipt of the frame.
Parameter:
B.6.2 ADPM-DISCOVERY.indication
The ADPM-Discovery.indication primitive is generated by the ADP layer upon Beacon reception. This primitive
will be generated as many times as number of Beacons are received, thus it is an Application task to decide
which PAN to join, depending on the info received on each of the indications.
struct TAdpPanDescriptor {
uint16_t m_u16PanId;
uint8_t m_u8LinkQuality;
uint16_t m_u16LbaAddress;
uint16_t m_u16RcCoord;
};
B.6.3 ADPM-DISCOVERY.confirm
The ADPM-DISCOVERY.confirm primitive is generated by the ADP layer upon completion of a previous ADPM-
DISCOVERY.request.
Parameter:
Parameter:
u16PanId The PANId of the network to create; determined at the application level [Valid
range: 0x0000 - 0xFFFF].
B.6.5 ADPM-NETWORK-START.confirm
The ADPM-NETWORK-START.confirm primitive reports the status of an ADPM-NETWORK-START.request
Structure:
struct TAdpNetworkStartConfirm {
uint8_t m_u8Status;
};
Parameter:
B.6.6 ADPM-NETWORK-JOIN.request
The ADPM-NETWORK-JOIN.request primitive allows the upper layer to join an existing network.
Parameters:
u16LbaAddress The 16-bit short address of the device acting as a LoWPAN bootstrap agent as
defined in Annex E of G3 Spec.
B.6.7 ADPM-NETWORK-JOIN.confirm
The ADPM-NETWORK-JOIN.confirm primitive is generated by the ADP layer to indicate the completion status
of a previous ADPM-NETWORK-JOIN.request.
Structure:
struct TAdpNetworkJoinConfirm {
uint8_t m_u8Status;
uint16_t m_u16NetworkAddress;
Fields:
m_u16NetworkAddress The 16-bit network address that was allocated to the device. If the allocation
fails, this address is equal to 0xFFFF.
m_u16PanId The 16-bit address of the PAN of which the device is now a member.
B.6.8 ADPM-NETWORK-JOIN.indication
Not implemented.
B.6.9 ADPM-NETWORK-LEAVE.request
The ADPM-NETWORK-LEAVE.request primitive allows a non-coordinator device to remove itself from the
network.
void AdpNetworkLeaveRequest(void);
B.6.10 ADPM-NETWORK-LEAVE.indication
ADPM-NETWORK-LEAVE.indication primitive is generated by the ADP layer of a non-coordinator device to
inform the upper layer that it has been unregistered from the network by the coordinator.
B.6.11 ADPM-NETWORK-LEAVE.confirm
The ADPM-NETWORK-LEAVE.confirm primitive allows the upper layer to be informed of the status of its
previous ADPM-NETWORK-LEAVE.request.
m_u8Status The status of the request.
Structure:
struct TAdpNetworkLeaveConfirm {
uint8_t m_u8Status;
};
Field:
B.6.12 ADPM-RESET.request
The ADPM-RESET.request primitive performs a reset of the adaptation sublayer and allows the resetting of the
MIB attributes.
B.6.13 ADPM-RESET.confirm
The ADPM-RESET.confirm primitive allows the upper layer to be notified of the completion of an ADPM-
RESET.request primitive.
Structure:
struct TAdpResetConfirm {
uint8_t m_u8Status;
};
Field:
B.6.14 ADPM-GET.request
The ADPM-GET.request primitive allows the upper layer to get the value of an attribute from the ADP information
base.
Parameters:
u16AttributeIndex The index within the table of the specified IB attribute to read. This parameter
is valid only for IB attributes that are tables.
A synchronous implementation of this function is also available, thus no confirm is generated, instead a pointer
to confirm structure has to be provided.
Parameters:
u16AttributeIndex The index within the table of the specified IB attribute to read. This parameter
is valid only for IB attributes that are tables.
pGetConfirm Pointer to confirm structure to get the result. See structure definition in Confirm
primitive definition below.
B.6.15 ADPM-GET.confirm
The ADPM-GET.confirm primitive allows the upper layer to be informed of the status of a previously issued
ADPM-GET.request primitive.
Structure:
struct TAdpGetConfirm {
uint8_t m_u8Status;
uint32_t m_u32AttributeId;
uint16_t m_u16AttributeIndex;
uint8_t m_u8AttributeLength;
uint8_t m_au8AttributeValue[64];
};
Fields:
m_u16AttributeIndex The index within the table of the specified IB attribute to read. This parameter
is valid only for IB attributes that are tables.
m_u8AttributeLength The length of the value of the attribute read from the IB.
B.6.16 ADPM-MAC.GET.request
The ADPM-MAC.GET.request primitive allows the upper layer to get the value of an attribute from the MAC
information base. The upper layer cannot access directly the MAC layer while ADP is running.
Parameters:
u16AttributeIndex The index within the table of the specified IB attribute to read. This parameter
is valid only for IB attributes that are tables.
A synchronous implementation of this function is also available, thus no confirm is generated, instead a pointer
to confirm structure has to be provided.
u16AttributeIndex The index within the table of the specified IB attribute to read. This parameter
is valid only for IB attributes that are tables.
pGetConfirm Pointer to confirm structure to get the result. See structure definition in Confirm
primitive definition below.
B.6.17 ADPM-MAC.GET.confirm
The ADPM-MAC.GET.confirm primitive allows the upper layer to be informed of the status of a previously issued
ADPM-MAC.GET.request primitive.
Structure:
struct TAdpMacGetConfirm {
uint8_t m_u8Status;
uint32_t m_u32AttributeId;
uint16_t m_u16AttributeIndex;
uint8_t m_u8AttributeLength;
uint8_t m_au8AttributeValue[MAC_PIB_MAX_VALUE_LENGTH];
};
Fields:
m_u16AttributeIndex The index within the table of the specified IB attribute read.
m_u8AttributeLength The length of the value of the attribute read from the IB.
Parameters:
A synchronous implementation of this function is also available, thus no confirm is generated, instead a pointer
to confirm structure has to be provided.
Parameters:
pSetConfirm Pointer to confirm structure to get the result. See structure definition in Confirm
primitive definition below.
B.6.19 ADPM-SET.confirm
The ADPM-SET.confirm primitive allows the upper layer to be informed about a previous ADPM-SET.request
primitive.
Structure:
struct TAdpSetConfirm {
uint8_t m_u8Status;
uint32_t m_u32AttributeId;
uint16_t m_u16AttributeIndex;
};
Fields:
B.6.20 ADPM-MAC.SET.request
The ADPM-MAC.SET.request primitive allows the upper layer to set the value of an attribute in the MAC
information base. The upper layer cannot access directly the MAC layer while ADP is running.
Parameters:
A synchronous implementation of this function is also available, thus no confirm is generated, instead a pointer
to confirm structure has to be provided.
Parameters:
pSetConfirm Pointer to confirm structure to get the result. See structure definition in Confirm
primitive definition below.
Structure:
struct TAdpMacSetConfirm {
uint8_t m_u8Status;
uint32_t m_u32AttributeId;
uint16_t m_u16AttributeIndex;
};
Fields:
B.6.22 ADPM-NETWORK-STATUS.indication
The ADPM-NETWORK-STATUS.indication primitive allows the next higher layer of a PAN coordinator or a
coordinator to be notified when a particular event occurs on the PAN.
Structure:
struct TAdpNetworkStatusIndication {
uint16_t m_u16PanId;
struct TAdpAddress m_SrcDeviceAddress;
struct TAdpAddress m_DstDeviceAddress;
uint8_t m_u8Status;
uint8_t m_u8SecurityLevel;
uint8_t m_u8KeyIndex;
};
Structure:
struct TAdpBufferIndication {
bool m_bBufferReady;
};
The parameter m_bBufferReady indicates whether there are buffers available or not. This primitive is generated
by ADP layer when a data transmission takes the last available buffer, indicating that there are no more free
buffers, and is also generated when, after no buffers are available, one of them becomes free for a new
transmission.
B.6.24 ADPM-PREQ.indication
The AdpPREQIndication primitive allows the next higher layer to be notified when a PREQ frame is received in
unicast mode with Originator Address equal to Coordinator Address and with Destination Address equal to
Device Address.
This primitive is generated by ADP layer in order to indicate upper layer that the device has been addressed by
means of a PREQ frame.
B.6.25 ADPM-UPD_NON_VOLATILE_DATA.indication
The AdpUpdNonVolatileDataIndication primitive allows the next higher layer to be notified when any of the
parameters to be saved/restored before/after a reset changes, this way, upper layer can maintain a record of
these parameters always updated.
It is up to the upper layer how to handle the change of these parameters, and their storage if necessary.
B.6.26 ADPM-BROKEN_ROUTE.indication
The AdpBrokenRouteIndication primitive is used to indicate the upper layer that a route has just broken due to
no ACK reception for the frame being transmitted, this way, upper layer knows that a Route Repair process will
be triggered to find an alternative route to send such frame, or even cancel the Route Repair mechanism by
using ADP_IB_MANUF_TRIGGER_REPAIR_ON_ROUTE_BROKEN parameter (please note this Repair
cancellation is out of spec).
struct TAdpBrokenRouteIndication{
uint16_t m_u16SrcAddr;
uint16_t m_u16DestAddr;
uint16_t m_u16NextHopAddr;
uint16_t m_u16NsduLength;
uint8_t *m_pNsdu;
};
Field:
m_u16SrcAddr Originator address of the frame which caused the Route break.
m_u16DestAddr Final destination address of the frame which caused the Route break.
m_u16NextHopAddr Next hop in Route to be deleted. In case there is no Route to delete, reported
value is 0xFFFF.
B.6.27 ADPM-ROUTE-DISCOVERY.request
The ADPM-ROUTE-DISCOVERY.request primitive allows the upper layer to initiate a route discovery.
Parameters:
u8MaxHops This parameter indicates the maximum number of hops allowed for the route
discovery [Valid range: 0x01 - 0x0E].
B.6.28 ADPM-ROUTE-DISCOVERY.confirm
The ADPM-ROUTE-DISCOVERY.confirm primitive allows the upper layer to be informed about a previous
ADPM-ROUTE-DISCOVERY.request primitive.
struct TAdpRouteDiscoveryConfirm {
uint8_t m_u8Status;
};
Field:
B.6.29 ADPM-PATH-DISCOVERY.request
The ADPM-PATH-DISCOVERY.request primitive allows the upper layer to initiate a path discovery.
Parameters:
u8MetricType The metric type to be used for the path discovery. (Range: 0x00 - 0x0F).
B.6.30 ADPM-PATH-DISCOVERY.confirm
The ADPM-PATH-DISCOVERY.confirm primitive allows the upper layer to be informed of the completion of a
path discovery (ADPM-PATH-DISCOVERY.request).
Structure:
struct TAdpPathDiscoveryConfirm {
uint8_t m_u8Status;
uint16_t m_u16DstAddr;
uint16_t m_u16OrigAddr;
uint8_t m_u8MetricType;
uint8_t m_u8ForwardHopsCount;
uint8_t m_u8ReverseHopsCount;
struct THopDescriptor m_aForwardPath[16];
struct THopDescriptor m_aReversePath[16];
};
Fields:
m_u8Status The status of the path discovery. (status can be INCOMPLETE and the
other parameters contain the discovered path).
B.6.31 ADPM-LBP.request
The ADPM-LBP.request primitive allows the upper layer of the client to send the LBP message to the server
modem.
void AdpLbpRequest(const struct TAdpAddress *pDstAddr, uint16_t u16NsduLength, uint8_t *pNsdu, uint8_t
u8NsduHandle, uint8_t u8MaxHops, bool bDiscoveryRoute, uint8_t u8QualityOfService, bool bSecurityEnable);
Parameters:
pDstAddr 16-bit address of LBA or LBD or 64 bit address (extended address of LBD).
u8NsduHandle The handle of the NSDU to transmit. This parameter is used to identify in the
AdpLbpConfirm primitive which request is concerned. It can be randomly
chosen by the application layer.
u8MaxHops The number of times the frame will be repeated by network routers.
bDiscoveryRoute If TRUE, a route discovery procedure will be performed prior to sending the
frame if a route to the destination is not available in the routing table. If FALSE,
no route discovery is performed.
u8QualityOfService The requested quality of service (QoS) of the frame to send. Allowed values
are:
0x00 = standard priority
0x01 = high priority
bSecurityEnable If TRUE, this parameter enables the MAC layer security for sending the frame.
B.6.32 ADPM-LBP.confirm
The ADPM-LBP.confirm primitive reports the result of a previous ADPM-LBP.request primitive.
struct TAdpLbpConfirm {
uint8_t m_u8Status;
uint8_t m_u8NsduHandle;
};
Fields:
B.6.33 ADPM-LBP.indication
The ADPM-LBP.indication primitive is used to transfer a received LBP frame from the ADP layer to the upper
layer.
Structure:
struct TAdpLbpIndication {
uint16_t m_u16SrcAddr;
uint16_t m_u16NsduLength;
uint8_t *m_pNsdu;
uint8_t m_u8LinkQualityIndicator;
bool m_bSecurityEnabled;
};
Fields:
m_bSecurityEnabled TRUE if the frame was received with a security level greater or equal to
adpSecurityLevel, FALSE otherwise.
0x00: TYPE_HOP_COUNT
0x0E: TYPE_METRIC_CAPACITY
0x0F: TYPE_METRIC_COMPOSITE
Bytes 0 - 1: indicate the valid time in minutes. The value is a 16 bits integer encoded little endian (LSB
first).
Byte 2: indicates the validity of the CID for compression purposes (corresponds to C field from the IC-
MPv6 / 6CO message). A value of 0 means false, 1 means true.
Byte 3: indicates the context length in bits.
Bytes 4 - 19 (variable length): indicate the context value.
Bytes 0 - 1: indicate the source address of the broadcast packet (the address of the broadcast initiator).
The address is encoded little endian (LSB first)
Byte 2: indicates the sequence number
Bytes 3 - 4: indicate the remaining time in minutes until when this entry in the broadcast log table is
considered valid (encoded little endian, LSB first)
The length of each element is 2 bytes, defining the group address encoded little endian (lsb first). If the attribute
element is set with the length 0, the group is deleted.
When reading the element, an extra byte is added which indicates if the entry is valid or not: 0 means invalid, 1
means valid.
0: PAN device
1: PAN coordinator
2: Not defined (Default)
FALSE (Default).
TRUE: default routing.
The size of the attribute is 1 byte. Default value is 0, which means that coordinator is not a neighbour and there
is no route to reach it (typically before start exchanging any data with it).
Parameters:
None
C.2.2 Re-keying
In order to launch a re-keying procedure, the following function must be called:
Parameters:
None
See [4] for details about the procedure, and C.3.6 and C.3.7 to set the current and new GMK.
Parameters:
None
Parameters:
The function returns the short address assigned to the device stored in that entry of the table. The short
addresses are assigned sequentially to the devices, in order of arrival, starting from the value defined in
LBP_IB_INITIAL_SHORT_ADDRESS (see C.3.3 below).
Parameters:
The function returns true in case the requested entry exists, and false otherwise.
C.2.4 Kick
As described in the G3 specification [4], the kick procedure can be initiated by the device or by the coordinator.
For the coordinator to start a kick procedure, the following function must be used:
Parameters:
Parameters:
Parameters:
Parameters:
None
The callbacks are returned in the structure pointed by TBootstrapAdpNotifications *, defined like this:
typedef struct {
AdpLbpConfirm fnctAdpLbpConfirm;
AdpLbpIndication fnctAdpLbpIndication;
}TBootstrapAdpNotifications;
LBP module also offers the possibility to upper layer of setting callbacks in order to be notified when a Device
Joins or Leaves the Networtk, by means of the functions:
Parameters:
pf_app_leave_ind_cb_t pf_handler Pointer to function which will be called when a Device Leaves the
Network
pf_app_join_ind_cb_t pf_handler Pointer to function which will be called when a Device Joins the
Network
DISCLAIMER: The information in this document is provided in connection with Atmel products. No license, express or implied, b y estoppel or otherwise, to any intellectual property right
is granted by this document or in connection with the sale of Atmel products. EXCEPT AS SET FORTH IN THE ATMEL TERMS AND CONDITIONS OF S ALES LOCATED ON THE
ATMEL WEBSITE, ATMEL ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON -INFRINGEMENT. IN NO EVENT
SHALL ATMEL BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENT AL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES
FOR LOSS AND PROFITS, BUSINESS INTERRUPTION, OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT , EVEN IF ATMEL
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this
document and reserves the right to make changes to specifications and products descriptions at any time without notice. Atmel does not make any commitment to update the information
contained herein. Unless specifically provided otherwise, Atmel products are not suitable for, and shall not be used in, auto motive applications. Atmel products are not intended,
authorized, or warranted for use as components in applications intended to support or sustain life.
SAFETY-CRITICAL, MILITARY, AND AUTOMOTIVE APPLICATIONS DISCLAIMER: Atmel products are not designed for and will not be used in conne ction with any applications where
the failure of such products would reasonably be expected to result in significant personal injury or death (“Safety-Critical Applications”) without an Atmel officer's specific written consent.
Safety-Critical Applications include, without limitation, life support devicesAtmel Confidential:
and systems, equipmen For
t or Release Only
systems for the Under
operationNon-Disclosure Agreement
of nuclear facilities and weapons (NDA)
systems. Atmel
products are not designed nor intended for use in military or aerospace applications or environments unless specifically desi gnated by Atmel as military-grade. Atmel products are not
designed nor intended for use in automotive applications unless specifically designated by Atmel as automotive -grade. Atmel G3-PLC FW Stack User Guide 105 1
Atmel-43081W-ATPL-G3-PLC_Firmware_Stack-User Guide_6-Apr-17
0
5