NXP Semiconductors
UM11038
OM27642 Smart Lock KIT
UM11038
All information provided in this document is subject to legal disclaimers.
© NXP B.V. 2018. All rights reserved.
User manual
COMPANY PUBLIC
Rev. 1.1 — 11 October 2018
407611
20 of 38
11. Structure of the QN Firmware
The QN firmware is built on NXP Bluetooth Low Energy library. This library implements a
proprietary profile which is optimized sending and receiving APDU commands. It
automatically splits data onto several Bluetooth Low Energy packets if necessary. In
addition, the library uses the Bluetooth Low Energy feature to send several Bluetooth
Low Energy packets in one communication interval to speed up communication.
All data is transferred using unacknowledged Bluetooth Low Energy packets:
•
Write Commands (Bluetooth Low Energy client to QN)
•
Notifications (QN to Bluetooth Low Energy client)
Data sheet QN902x:
http://www.nxp.com/documents/data_sheet/QN902X.pdf
Application note:
http://www.nxp.com/documents/application_note/AN11664.pdf
The communication with PN is basically done by two modules:
•
app_pn_task.c: The PN TASK handles the whole communication with the PN. It
controls the state, interprets the commands and starts/stops the communication
•
pn_nfc.c: driver to communicate with PN. This module handles the low-level
functions to communicate with PN. It contains functions which run the context of
the GPIO interrupt as well as UART interrupt. In case of an event this module will
send a message to the PN TASK which will handle the event in a synchronous
way.
Note: In the download area only the binary files are provided.
11.1 src\app\pn\app_pn_task.c
The PN TASK has the overall responsibility to take actions and control the state of the
QN. This means that all input from PN (UART data but also GPIO wake-up events) is
converted to messages and sent via messages queues to the PN TASK.
To send messages to the PN TASK this module provides global functions which build
and send the appropriate messages.
From the QN point of view two events may start a transaction and thus the
communication with the PN:
•
PN is woken up by proximity sensor or micro switch and wants to communicate
with QN. The handshake sequence may start immediately.
•
A Bluetooth Low Energy client connects to QN. QN has to power on PN before
starting with the handshake sequence.
The PN_TASK basically uses three app states:
•
PN_STATE_IDLE: QN advertises and uses low power mode. Sleep mode is not
possible since RTC must be powered. The task is waiting either for a Bluetooth
Low Energy connection or a wake-up event from PN via GPIO line.
•
PN_STATE_BLE_ACTIVE: A Bluetooth Low Energy Client has connected and
subscribed to receive notifications from QN. In this state the PN_TASK acts as a
kind of proxy between the Bluetooth Low Energy client and the PN, meaning it
transfers APDU commands from PN to the Bluetooth Low Energy client and
APDU responses in the other direction.
•
PN_STATE_NFC_ACTIVE: PN is powered up (e.g. proximity sensor) and wants
to read the current RTC value from QN. In this state no APDUs are exchanged
since those are handled locally between the PN and a NFC medium directly. Still