S110 Serialization

Architecture

The BLE S110 Serialization makes it possible to place a Bluetooth Application on an application chip and connect it to a connectivity chip running the BLE nrf518_lib_ble_s110.

Connectivity Chip: The nRF51822 chip running the BLE S110 SoftDevice.
Bluetooth Application Board: The nRF51822 chip running a serialized application, where the BLE S110 SoftDevice is replaced by the Commands Encoder and Events Decoder. The nRF51822 does not have the BLE S110 SoftDevice.

On the Bluetooth Application Board, the BLE S110 SoftDevice is replaced by a codec implementing the S110 SoftDevice API. All function calls to the codec will be serialized and transmitted to the BLE S110 Connectivity Chip using the Transport Layer and UART driver. This design makes it possible to substitute an existing layer, such as UART with SPI, without affecting the codec.

The BLE S110 Connectivity Chip will decode the serialized commands from the Bluetooth Application Board and execute the corresponding function in the S110 SoftDevice.
Any event from the S110 SoftDevice is encoded by the codec and transmitted to the Bluetooth Application Board using the the transport layer and UART.
On the Bluetooth Application Board the event is decoded and passed to the application.

BLE S110 Serialization simplifies the serialization of an existing Bluetooth application, since limited modifications are needed in the application itself. Serialization of an existing application requires Command Encoder, Event Decoder, HCI Transport and SLIP module which are used in the project instead of the S110 SoftDevice.

See Serialization nRFgo Motherboard Setup - Serialization on how to flash and wire a Bluetooth Application Board with a BLE S110 Connectivity chip.

Architectural overview of Serialized <i>Bluetooth</i> Application.

HCI Transport Layer

The BLE S110 Serialization example transmits and receives commands, command responses, and events over UART.

In Bluetooth two UART transport layer protocols are commonly in use.

• Bluetooth Specification 1.1, Part H:4, HCI UART Transport Layer, (known as H4)
• Bluetooth Specification 4.0, Volume 4, Part D, Three-wire transport layer.

The Transport Layer for spec. 1.1, H4, is a very simple and lightweight transport layer, which works very well in noise-free environment and reliable UART.

The Transport Layer for specification 4.0 is more complex and overhead on the wire due to transmission of acknowledgement packets and re-transmissions. The use of acknowledgement packets make the transport layer more robust and reliable but it has associated costs in terms of larger code size, larger memory footprint. It also makes transmission duration longer because of retransmission.

A brief comparison between HCI Transport Layer for specification 1.1 and 4.0 can be seen in the table below.

HCI UART Transport Layer, v 1.1 (H4)	HCI Transport Layer, v4.0
Simple	Complex
Fast (No ACK packets)	Slower (ACK packets)
Unreliable in noisy environments	Very reliable (retransmission)
Smaller code/memory footprint	Larger code/memory footprint

The BLE S110 Serialization examples provides the ability to use the reliable Three-wire Transport Layer, ver. 4.0.

The Three-wire Transport Layer offers reliable transport layer when developing a two chip solution where the nRF51822 is used as the connectivity chip. For the prototyping setup presented in nRFgo Motherboard Setup - Serialization , this solution ensures correct transmission and retransmission of packets even when long cables, high baud rates, and noisy environments are taken into consideration. This allows the developer to concentrate on developing the right application without concerns for the communication layer.

It guarantees reliable transfer of packets when connecting the nRF51822 chip to PC UART / USB-UART connectors, which can vary in reliability, especially at higher baud rates.

It is recommended during prototyping and/or early development of nRF51822 product, HCI Transport Layer V4.0 could be used. However after gaining confidence and ensuring robustness and reliability at application level for the final product, it is recommended to switch over to the HCI UART Transport Layer, H4.

The nRF51822 chip offers a reliable UART, even at high baud rates. Therefore acknowledgement of packets and retransmission can be disabled in order to reduce the memory/flash footprint and reduce power consumption. This can be achieved by removing the acknowledgement packets and retransmission from hci_transport.c .

HCI - Transport Layer - System integration

The image below shows the internal architecture of a serialized BLE S110 SoftDevice.

Internal architecture of a serialized BLE S110 SoftDevice.

The image below shows the various threads of execution within the serialized BLE S110 Connectivity Chip.

Various threads of execution within the serialized BLE S110 Connectivity Chip.

1. SoftDevice command decode and event encode context: MAIN priority context
   1.1 SoftDevice command API call as an output of command decode: MAIN priority context
2. UART TX/RX ISR calls: APP-LO priority context
3. hci_transport retransmission timeout context: APP-LO priority context
4. SoftDevice events: MAIN priority context

The image below shows an example internal architecture of an application chip controlling the serialized BLE S110 SoftDevice.

An example of internal architecture of an application chip.

The image below shows an example of various threads of execution which could be executing within an application chip controlling the serialized BLE S110 SoftDevice.

An example of various threads of execution within the application chip.

1. SoftDevice calls: MAIN priority context
2. UART TX/RX ISR calls: APP-LO priority context
3. hci_transport retransmission timeout context: APP-LO priority context

Note

The current application chip reference design has been validated using the priority context setup as defined in the above figure. Any deviation from this model can lead to undefined behavior.

The image below shows an MSC of a single basic TX path cycle.

Basic TX path cycle.

1. TX codec allocates TX packet memory and issues a packet write request. Request is processed throughout the stack and asynchronous packet write to the UART hardware is started. TX codec receives the status of the request via return code (NRF_SUCCESS), which informs it that a packet was added to the transmission queue and an event will be send upon transmission completion.
2. TX buffer is eventually transferred completely and a corresponding event gets propagated to hci_transport which will omit propagating it to TX codec until a valid ACK for the TX packet is received.
3. Valid ACK for TX packet is received, which will complete the TX cycle and is reported to the TX codec.
4. TX codec received the information of a completed TX cycle and can free the corresponding TX buffer or reuse it for future TX requests.

The image below shows an MSC of a TX path cycle where TX path is 1st stopped due TX queue been filled up and after correct event reception resumed.

TX path queue full cycle.

1. TX codec allocates TX packet memory and issues a packet write request. Request is processed throughout the stack and asynchronous packet write to the UART hardware is started. TX codec receives the status of the request via return code (NRF_SUCCESS), which informs it that a packet was added to the transmission queue and an event will be send upon transmission completion.
2. TX codec allocates new TX packet memory and issues a new packet write request while the previous request is still in progress. This request will fail (NRF_ERROR_NO_MEM) because the transmission queue is full and the packet was not added. Before issuing this operation again the appropriate event needs to occur.
3. Valid ACK for the TX packet is received. This completes the TX cycle and is reported to the TX codec which can re-issue the packet write request.

The image below shows an MSC of a single basic RX path cycle.

Basic RX path cycle.

1. Free RX memory block is produced by hci_transport and given to hci_slip layer to be used as an RX buffer. RX data is received through the UART, which will be decoded by the hci_slip layer and an event is send to hci_transport layer once a valid slip packet has been received.
2. Valid RX packet is decoded by hci_transport layer and corresponding ACK packet is written to TX queue (if available space exists otherwise it is discarded). Actual length of the received RX packet is stored to the corresponding RX memory block. New free RX memory block is produced by hci_transport and given to hci_slip layer to be used as RX buffer.
3. An event is send to the RX codec when a valid RX packet is received. The received packet is extracted and processed by the RX codec allowing the memory to be reused by the hci_transport layer.

BLE S110 Connectivity Chip

Advertising Application Serialized

Heart Rate Application - Serialized