Project Name: [Your Project Name]
Version: [Version Number]
Date: [Date]
Author: [Your Name]

TABLE OF CONTENTS

• 1. Introduction
  • 1.1 Purpose
  • 1.2 Scope
  • 1.3 Prerequisites
• 2. Acceptance Criteria
• 3. Test Setup
  • 3.1 Software Setup
  • 3.2 Hardware Setup
• 4. Test Cases
  • 4.0 Firmware Compilation
  • 4.1 Device Power-On Test
  • 4.2 RemoteAPI Functionality Test
  • 4.3 OTAP Test
  • 4.4 CPU Usage
• 5. Test Results Summary
• 6. References

1. Introduction

1.1 Purpose

This document defines the Acceptance Test Plan (ATP) to verify that a connected node (router, non router, autorole) is functional enough to be updated remotely. By following these test cases, the client will ensure that the device meets the minimum requirements for a successful remote update (OTAP).

1.2 Scope

The ATP covers essential functional and connectivity tests required before deploying a node. It ensures that:

• The device powers on and boots correctly.
• Basic network functionality is available.
• The device can connect to the update server.
• The remote API command can be initiated.
• The device can be updated remotely.

1.3 Prerequisites

• Hardware: [Device Model], [MCU]
• Software: [Stack Version], [SDK Version], [Build tool version]
• Tools: [Sink], [Gateway], [WNT Instance] or [MQTT Broker]

2. Acceptance Criteria

The device must meet the following criteria to pass acceptance testing:

• Successfully boots into the required firmware.
• Joins an existing network.
• Responds to basic functionality checks.
• Answers to remote API commands.
• Successfully completes an OTAP.

3. Test Setup

3.1 Software Setup

1. Ensure the correct firmware version is installed before testing.
2. Set up a test environment with controlled network conditions.

3.2 Hardware Setup

1. One gateway providing access to a local MQTT broker or a WNT instance.
2. A sink plugged into the Gateway with diagnostics activated.
3. The Device Under Test (DUT).

4. Test Cases

4.0 Firmware Compilation

Objective: Ensure the firmware compiles without errors or warnings.

Procedure:
Run the compilation commands in the SDK:

docker run --rm -v `pwd`:/home/wirepas/wm-sdk -w /home/wirepas/wm-sdk -ti wirepas/sdk-builder:v1.5 make app_name=<your app> target_board=<your board>

Expected Result:

• 4.0.1: No errors or warnings produced.
• 4.0.2: A build/<board>/<app>/final_image_<app>.hex file is generated for flashing.

4.1 Device Power-On Test

The Wirepas stack includes a mechanism that allows all nodes to periodically send diagnostic data to the sink. These diagnostics use source endpoint 247 and destination endpoint 255. They can be used to analyze the functionality of nodes in the network. They are sent at boot time and at regular intervals.

Objective:
 Ensure the device powers on and boots successfully through the use of diagnostics message.

Procedure:

• Flash the firmware generated (final_image_<app>.hex).
• Power device under test.

Expected Result:

• 4.1.1: The device boots and joins the sink : a boot diagnostics is received by the sink.
• 4.1.2: node is sending diagnostics message using this interval configured in 3.2.2. 

Diagnostics datas are packets sent by the stack. Their source endpoint is 247, and destination endpoint 255. They can be received like any other application message using Wirepas MQTT Console.

4.2 RemoteAPI Functionality Test

Wirepas provides a way to reconfigure nodes remotely : it's the Remote API .
 Requests and responses are sent as regular data packets on special endpoints.

Objective:
Ensure the device can handle RemoteAPI commands so that it can be re-configured in the field.

Procedure:

• Send a RemoteAPI 'Ping' message. (RemoteAPI payload 0x0000).
• Send a RemoteAPI 'MSAP Scratchpad Status' (RemoteAPI payload 0x1900).
• Change node address (RemoteAPI payload 0x0400 0100 0D06010056341200 0300 05020A00).
• Change node role (RemoteAPI payload0x0400 0100 0D03040003 0300 05020A00).

Remote API message are packets sent from endpoint 255 to endpoint 240 like any other application message. They could be sent and received using Wirepas MQTT Console.

Expected Result:

• 4.2.1: A ping message is received by the sink.
  RemoteAPI answer received with payload starting with 0x8000
• 4.2.2: A full scratchpad status is sent to the sink. The payload indicates that no scratchpad is present in the node.
  Remote API answer begin with 0x99. If byte 9 is cleared, there are no scratchpad present.
• 4.2.3: After 180s, the node reboots and get a new node address (0x123456).
   The node coming back after reboot got a new node address.
• 4.2.4: After 180s, the node reboots and get a new role. 
   The node coming back after reboot should be a low-energy non router node.

Node role can be checked using WNT, or using RemoteAPI message Read CSAP Attribute commands.

4.3 OTAP Test

Objective: Ensure the device can receive an OTAP and process it to be updated in the field.

Procedure:

• Load a scratchpad into the sink, set action to PROPAGATE, and issue a RemoteAPI MSAP Scratchpad Status command. 
• Change OTAP action to PROPAGATE AND PROCESS in the sink.
• Issue MSAP Scratchpad StatusRemoteAPI command.

Scratchpad and their associated OTAP actions can be loaded using WNT or Wirepas MQTT Library.

Expected Result:

• 4.3.1: The Scratchpad status indicates that a valid Scratchpad is present with Sequence/CRC/Size corresponding to the one uploaded in the sink.
• 4.3.2: The node should reboot with the new firmware. At reboot, it should transmit a boot diagnostic.
• 4.3.3: The MSAP Scratchpad Status should confirm that the new scratchpad is processed without any errors. If byte 10 is cleared, there was a scratchpad processed successfully by the bootloader.

4.4 CPU Usage

Objective: Ensure that the application does not consume excessive CPU time and give enough time to the stack

Procedure:

• Instrument code to toggle a GPIO when entering/exiting tasks.
• Instrument code to toggle a GPIO when entering/exiting callback.
• Instrument code to toggle a GPIO when entering/exiting interrupt.
• Monitor GPIOs using a logic analyzer.

Expected Result:

• 4.4.1: None of the tasks should use more than 100ms.
• 4.4.2: Tasks must not exceed their allocated execution time.
• 4.4.3: The CPU must be idle for at least 50ms.
• 4.4.4: Time in callbacks must not exceed 1ms
• 4.4.5: Time in interrupts must not exceed 50uS

5. Test Results Summary

6. References

1. Wirepas Local Network Setup Guide
2. All nodes in Wirepas can periodically send diagnostics data to the backend. These diagnostics can be used to analyze the node's functionality in the network. Their source endpoints are 247 and destination endpoint 255.
3. Wirepas Massive Remote API Reference Manual
4. Node update using WNT
5. Wirepas MQTT Library
6. Execution Time Limits : Wirepas SDK Application Operation
7. Wirepas MQTT Console : https://developer.wirepas.com/support/solutions/articles/77000561183-how-to-use-wirepas-mqtt-console-
8. Wirepas MQTT Library : https://github.com/wirepas/wirepas-mqtt-library