Developer Guide - MCU Local Voice Control Kit · on the high performance i.MX RT106L...

NXP Semiconductors Document Number: SLN-LOCAL-IOT-DG

Solution Developer’s Guide Rev. 1.1, 02/2020

MCU Local Voice Control Solution Developer’s Guide

CONTENTS

1. INTRODUCTION ............................................................................................................................................ 6

2. GETTING TO KNOW THE SLN-LOCAL-IOT ....................................................................................................... 6

2.1 HARDWARE OVERVIEW ......................................................................................................................................... 6 2.2 SOFTWARE OVERVIEW .......................................................................................................................................... 8 2.3 DEVICE MEMORY MAP ......................................................................................................................................... 8 2.4 SECURITY ARCHITECTURE ....................................................................................................................................... 9

2.4.1 Application Chain of Trust .................................................................................................................... 10 2.4.2 Flash Image Configuration Area (FICA) and Image Verification .......................................................... 10 2.4.3 Image Certificate Authority (CA) and Application Certificates ............................................................. 11

2.5 AUDIO APPLICATION ARCHITECTURE ...................................................................................................................... 11 2.6 APPLICATION LAYER API ...................................................................................................................................... 12 2.7 HOST INTERFACE ................................................................................................................................................ 12 2.8 PUSH BUTTON CONTROL ..................................................................................................................................... 13

3. LOCAL VOICE CONTROL ENGINE ................................................................................................................. 13

3.1 PROJECT ASSETS................................................................................................................................................. 13 3.2 SESSION FLOW ................................................................................................................................................... 14 3.3 DIALOGUE CONFIGURATION ................................................................................................................................. 15

4. GETTING STARTED WITH THE MCUXPRESSO TOOLS.................................................................................... 15

4.1 J-LINK DEBUGGER .............................................................................................................................................. 16 4.2 STARTING MCUXPRESSO IDE FOR THE FIRST TIME ................................................................................................... 16 4.3 INSTALLING THE SDK .......................................................................................................................................... 16 4.4 IMPORTING PROJECTS ......................................................................................................................................... 17 4.5 BUILDING AND PROGRAMMING............................................................................................................................. 19

4.5.1 Changing Image Verification Configuration ........................................................................................ 20 4.5.2 Programming the SLN-LOCAL-IOT ........................................................................................................ 22 4.5.3 Restoring Factory Settings ................................................................................................................... 23

5. BOOTLOADER ............................................................................................................................................. 25

5.1 APPLICATION FLOW ............................................................................................................................................ 25 5.2 APPLICATION MEMORY BANKS ............................................................................................................................. 26 5.3 OVER-THE-WIRE (OTW) UPDATE ......................................................................................................................... 29

5.3.1 Entering OTW Update Mode ................................................................................................................ 29 5.3.2 Unit Test via UART ............................................................................................................................... 31 5.3.3 Transfers .............................................................................................................................................. 31

MCU Local Voice Control Kit Developer Guide

2

5.3.4 JSON Messages .................................................................................................................................... 32 5.4 USB MASS STORAGE DEVICE (MSD) UPDATE ......................................................................................................... 34

6. AUTOMATED MANUFACTURING TOOLS ..................................................................................................... 36

6.1 ABOUT IVALDI.................................................................................................................................................... 36 6.2 REQUIREMENTS AND SETUP.................................................................................................................................. 36 6.3 CREATING A SIGNING ENTITY ................................................................................................................................ 36

6.3.1 Using Ivaldi to Generate Signing Artifacts ........................................................................................... 37 6.3.2 Open Boot Programming ..................................................................................................................... 38

6.4 ENABLING ENCRYPTED EXECUTION IN PLACE (EXIP) AND HIGH ASSURANCE BOOT (HAB) ................................................ 40 6.4.1 Generating the PKI and Signed Flashloader ......................................................................................... 40 6.4.2 Creating the Images ............................................................................................................................. 41 6.4.3 Generating Secure Binary .................................................................................................................... 43 6.4.4 Enabling High Assurance Boot (HAB) ................................................................................................... 43 6.4.5 Enabling and Programming the Signed and Encrypted Binaries .......................................................... 44

7. FILESYSTEM ................................................................................................................................................ 44

7.1 GENERATING NEW WAV FILES ............................................................................................................................. 45

8. REFERENCES ............................................................................................................................................... 46

9. REVISION HISTORY ..................................................................................................................................... 46

10. ACRONYMS ................................................................................................................................................. 46

Developer Guide - MCU Local Voice Control Kit

3

FIGURES

FIGURE 1. I.MX RT SOM (BASE BOARD). ............................................................................................................................... 7 FIGURE 2. VOICE SHIELD (TOP BOARD). ................................................................................................................................... 7 FIGURE 3. HIGH-LEVEL SOFTWARE ARCHITECTURE. ................................................................................................................... 8 FIGURE 4. BOOT SECURITY FLOWCHART. ................................................................................................................................. 9 FIGURE 5. SIGNING ENTITIES. .............................................................................................................................................. 10 FIGURE 6. AUDIO APPLICATION PIPELINE. ............................................................................................................................. 11 FIGURE 7. ASR SESSION FLOW............................................................................................................................................ 14 FIGURE 8. MCUXPRESSO IDE WORKSPACE CREATION. ........................................................................................................... 16 FIGURE 9. SDK PACKAGE LOCATION. ................................................................................................................................... 17 FIGURE 10. INSTALLED SDKS TAB. ....................................................................................................................................... 17 FIGURE 11. IMPORTING EXISTING SDK PROJECT. .................................................................................................................... 18 FIGURE 12. SELECT SLN-LOCAL-IOT BOARD. ...................................................................................................................... 18 FIGURE 13. SELECT PROJECT TO IMPORT. .............................................................................................................................. 19 FIGURE 14. BUILDING AN APPLICATION. ............................................................................................................................... 20 FIGURE 15. ENABLE IMAGE VERIFICATION IN THE BOOTSTRAP. .................................................................................................. 21 FIGURE 16. ENABLE IMAGE VERIFICATION IN THE BOOTLOADER. ............................................................................................... 21 FIGURE 17. RE-BUILD APPLICATION. .................................................................................................................................... 21 FIGURE 18. START A DEBUG SESSION. .................................................................................................................................. 22 FIGURE 19. PROBE SELECTION DIALOGUE. ............................................................................................................................ 22 FIGURE 20. J-LINK PROGRAMMING WINDOW........................................................................................................................ 23 FIGURE 21. OPENING THE GUI FLASH TOOL. ......................................................................................................................... 23 FIGURE 22. GUI FLASH TOOL WINDOW. .............................................................................................................................. 24 FIGURE 23. SELECT THE BINARY. ......................................................................................................................................... 24 FIGURE 24. PROGRAMMING STATUS DIALOGUE. .................................................................................................................... 25 FIGURE 25. BOOTLOADER FLOW. ........................................................................................................................................ 26 FIGURE 26. EDIT MEMORY CONFIGURATION. ........................................................................................................................ 27 FIGURE 27. PROJECT PROPERTIES. ....................................................................................................................................... 27 FIGURE 28. EDITING POST-BUILD STEPS. ............................................................................................................................... 28 FIGURE 29. POST-BUILD COMMANDS TO GENERATE .BIN FILE. .................................................................................................. 29 FIGURE 30. SERIAL PORT HEADER - J26. ............................................................................................................................... 30 FIGURE 31. OTW COMMAND VIA SHELL. .............................................................................................................................. 30 FIGURE 32. EDITING THE COM_PORT IN FWUPDATE_CLIENT.PY. ............................................................................................. 31 FIGURE 33. TRANSFER FORMAT. ......................................................................................................................................... 31 FIGURE 34. REQUEST / RESPONSE FLOW. ............................................................................................................................. 32 FIGURE 35. MSD UPDATE MODE LED. ................................................................................................................................ 35 FIGURE 36. SLN-LOCAL-IOT KIT MOUNTED AS A USB MASS STORAGE DRIVE. .......................................................................... 35 FIGURE 37. SIGNING ARTIFACT GENERATION USAGE. .............................................................................................................. 37 FIGURE 38. SIGNING ARTIFACT GENERATION EXCERPT............................................................................................................. 37 FIGURE 39. GENERATION OF CERTIFICATE BINARIES. ............................................................................................................... 37 FIGURE 40. IMAGE_BINARIES FOLDER CONTENTS. .................................................................................................................. 38 FIGURE 41. OUTPUT OF IVALDI OPEN BOOT PROGRAMMING. ................................................................................................... 39 FIGURE 42. UNSETTING OF THE XIP BOOT HEADER. ................................................................................................................ 41 FIGURE 43. CONVERTING TO .SREC FILE. ............................................................................................................................... 42 FIGURE 44. CHANGING FROM .S19 TO .SREC. ........................................................................................................................ 42 FIGURE 45. SECURE APP FILE NAMES. .................................................................................................................................. 43 FIGURE 46. RUNNING FILE_FORMAT.PY. ............................................................................................................................... 45


4

TABLES

TABLE 1. DEVICE MEMORY MAP. .......................................................................................................................................... 9 TABLE 2. PUSH BUTTON CONTROL WITH SW1 AND SW2. ....................................................................................................... 13


5

To run the demos and development tools required for the SLN-LOCAL-IOT kit, and up-to-date computer is required. The following are the system requirements for running the out-of-box demo:

Computer Type OS Version Serial Terminal Application

PC Windows 10 TeraTerm, PuTTY

Mac macOS Catalina Serial, CoolTerm, goSerial

PC Linux PuTTY

Once you’re ready to begin development, you will need to download MCUXpresso IDE. The current SDK is tested with versions 11.1.0 of MCUXpresso IDE and Segger J-Link v6.6x. To download MCUXpresso IDE, visit the following website: http://www.nxp.com/mcuxpresso

The following information is provided per Article 10.8 of the Radio Equipment Directive 2014/53/EU:

(a) Frequency bands in which the equipment operates. (b) The maximum RF power transmitted.

PN RF Technology (a) Frequency Range (b) Max Transmitted Power

SLN-LOCAL-IOT WiFi 2412MHz – 2472MHz 17.9dBm

EUROPEAN DECLARATION OF CONFORMITY (Simplified DoC per Article 10.9 of the Radio Equipment Directive 2014/53/EU) This apparatus, namely SLN-LOCAL-IOT, conforms to the Radio Equipment Directive 2014/53/EU. The full EU Declaration of Conformity for this apparatus can be found at this location: https://www.nxp.com/

System Requirements and Prerequisites

System Requirements and Prerequisites

https://www.nxp.com/mcuxpresso

https://www.nxp.com/


6

1. Introduction

NXP’s MCU Local Commands Voice Solution is a comprehensive, secure and cost-optimized voice control solution that enables customers to quickly get to market. Based on the high performance i.MX RT106L Microcontroller (MCU), the solution enables single chip voice control with plenty of power left over for user-specific tasks. SLN-LOCAL-IOT hardware highlights:

• Up to 600 MHz (528 MHz default) Cortex-M7 MCU core

• 1 MB of on-chip RAM (512 KB TCM)

• 32 MB HyperFlash memory for fast XiP (eXecute In Place)

• Three PDM MEMS microphones

• TFA9894 Class-D amplifier

• WiFi/Bluetooth combo chip

• Integrated Speaker

• GPIO expansion headers This solution is supported by a comprehensive and free suite of enablement from NXP and its partners including:

• MCUXpresso Suite of tools (IDE, SDK and corresponding tools)

• Hardware design files

• Software audio tuning tools

• Documentation

2. Getting to Know the SLN-LOCAL-IOT

This section will highlight both the hardware and software features of the SLN-LOCAL-IOT. In the following sections you will find details about the board itself and the high-level software design and architecture.

2.1 Hardware Overview The SLN-LOCAL-IOT kit is designed to provide a reference for a real product design. The board is designed using a small form factor and has taken into account many of the design considerations a hardware engineer would evaluate. With that said, NXP has also designed the hardware to have some of the key hallmarks of a traditional development kit.


7

Figure 1. i.MX RT SOM (base board).

Figure 2. Voice Shield (top board).


8

2.2 Software Overview The SLN-LOCAL-IOT kit has been built and designed in such a way that enables best security practices while keeping a development kit feel. The main security mechanism that has been implemented are image verification stages that are required for every image programmed onto the device. The sections below guide you through the overall software and security architectures and the implications they have during the development and production phases of your product development. Figure 3 shows a high-level software architecture diagram. This shows everything that is included in the SDK for the SLN-LOCAL-IOT package, though not all of the features are implemented in demo applications.

Figure 3. High-Level Software Architecture.

2.3 Device Memory Map To understand the various pieces of the system, it helps to see the memory map that NXP has developed for this application. There are many components required in the system to successfully boot and execute an application.


9

Table 1. Device Memory Map.

Name Start Address End Address Description

Boot Config Region 0x6000_0000 0x6000_0FFF Used for XIP and setting up flash

IVT 0x6000_1000 0x6000_1FFF Vector table

Bootstrap 0x6000_2000 0x6003_FFFF

Bootloader 0x6004_0000 0x601F_FFFF

SLN_Intelligence_Toolbox 0x6020_0000 0x602F_FFFF NXP Solutions software IP

Application Bank A 0x6030_0000 0x60CF_FFFF

Application Bank B 0x60D0_0000 0x616F_FFFF

Filesystem 0x6170_0000 0x61F7_FFFF Stores audio files and certificates

Crypto Context Backup 0x61F8_0000 0x61FB_FFFF Backup for encrypted XiP context

Flash Image Config Area 0x61FC_0000 0x61FF_FFFF FICA table used for secure boot

2.4 Security Architecture Figure 4 shows the series of checks that occur at boot time. There are configuration options in the various applications (ROM bootloader, bootstrap, bootloader) that will determine which sequence is followed. The state of the SLN-LOCAL-IOT kit from the factory is with all security checks disabled.

Figure 4. Boot Security Flowchart.

If at any point a signature check fails, in the case where High Assurance Booting (HAB) or image verification is enabled, the boot process stops.


10

2.4.1 Application Chain of Trust The basis of the security architecture implemented in the SLN-LOCAL-IOT is signed application images. Signing requires the use of a Certificate Authority (CA). NXP has its own CA for signing applications at the factory, but the CA is not something that is shared with customers. The CA is used to create signing entities for the bootloader and application. A certificate from the CA is stored in the SLN-LOCAL-IOT’s filesystem and is used to verify the signatures of the signing entity certificates. In addition, locally stored certificates from the signing entities are used to verify the signature of firmware images coming in Over-The-Wire (OTW) bootloader interface.

Figure 5. Signing Entities.

When creating new firmware images for a secure boot implementation, the Manufacturing Tools can be used alongside your unique CA.

2.4.2 Flash Image Configuration Area (FICA) and Image Verification The FICA table is a section inside the filesystem that is responsible for describing the images that will be booted. It contains information about the image and signatures of the applications that will be used to ensure that only verified firmware is executed. This ensures malicious images cannot be executed without it being signed with the certificate authority and certificate that is programmed into the filesystem. Before any image is jumped to, it is first verified using the signature from its associated FICA entry. For example, in the standard boot flow shown in Figure 4:

• The bootstrap will use the bootloader FICA entry to validate the bootloader

• The bootloader will use the AppA FICA entry to validate the AppA image

• The bootloader will use the AppB FICA entry to validate the AppB image For final production, the solution provides programming scripts to enable i.MX RT High Assurance Boot (HAB) to verify and protect the bootstrap component. Developers should enable HAB for their end product. The downside of having this security protection enabled is that programming new images can be a little more complex as it requires signature generation. Taking in consideration that this flow may be time consuming and not required


11

for basic development tasks, NXP introduced some bypasses to make the job easier for developers. These bypasses should not be deployed in production. Again, the default configuration of the SLN-LOCAL-IOT is to have HAB disabled and signature verifications bypassed. This is to ensure a smooth development experience.

2.4.3 Image Certificate Authority (CA) and Application Certificates The SLN-LOCAL-IOT kit comes pre-programmed with signed images (though signature verification is bypassed by default) as indicated in the Flash Image Configuration Area (FICA) and Image Verification section. The bootloader and demo application are signed using NXP’s test CA and can be used to ensure all images that are to be booted are authentic. The application signing certificates are located at the following locations in the filesystem:

• Address 0x61D00000 for Application Bank A

• Address 0x61D80000 for the bootloader The certificate for the CA (used to verify the application signing certificates) is located at address 0x61CC0000 in the filesystem.

2.5 Audio Application Architecture The audio capture application is implemented as a pipeline. The application can be configured to capture either two or three microphones (default is three). Since the i.MX RT106L device has so much processing power, the core is used to process the entire chain from PDM decimation to the automatic speech recognition (ASR) engine. Every 10 milliseconds the DMA moves raw PDM data from each of the microphones. This data is fed into the NXP Solutions PDM decimation software IP to convert the audio into 16-bit 16 kHz PCM data. When it comes out of the decimation block, it is fed to the audio front end (AFE) to perform noise suppression, beam forming and acoustic echo cancellation. At this point it is a single 16-bit 16 kHz mono audio signal.

Figure 6. Audio Application Pipeline.


12

The ASR works on multiples of 20 ms of audio data, so the audio_processing_task accumulates 40 ms worth of processed audio before sending it to the ASR for processing. The decision was made to accumulate 40ms since the ASR has a tick-tock duty cycle where the tick is quite fast and the tock consumes about 10% of the CPU. By accumulating 40 ms of audio, there is a single processing cycle for the ASR instead of two.

2.6 Application Layer API NXP has implemented a high-level application layer that the demo applications use. The API is defined in local_commands.h. This API is intended to simplify access to the various components of the voice recognition software “stack” and designed to make the application layer cleaner for developers. As with any high-level API, there are trade-offs that had to be made to make the API simple and clean. If your application requires customization at lower levels (such as using the ASR differently), the application layer implementation provided by NXP can be bypassed and used as a reference example for your custom software.

2.7 Host Interface For applications that need to interact with another processor, NXP has implemented a host interface. This allows the RT106L to notify the host processor of events as well as receive commands. The implementation provided by NXP uses the Embedded Remote Procedure Call (eRPC) system championed by NXP. Information about eRPC can be found here: https://github.com/EmbeddedRPC/erpc The RT106L implements both a client and server instance, so communication is bi-directional. If your system does not require bi-directional communication, either of the instances can be turned off. Likewise, if the host interface is not required, removing the definition for ERPC_HOST from both the C and C++ preprocessor definitions will remove the relevant code. On the client side, the RT106L sends eRPC notifications for the following events:

• ASR session started

• ASR command detected (along with command index) On the server side, the RT106L listens for the following events:

• Mute

• Unmute

https://github.com/EmbeddedRPC/erpc


13

• Reset

• Enter bootloader

• Change command set

2.8 Push Button Control There are two push buttons (SW1 and SW2) on the voice shield as shown in Figure 2. We can use them to control speaker volume of the kit. Press SW1 to increase the speaker volume and SW2 to decrease. The switches are also used in bootloader. To put the kit into Over-The-Wire (OTW) update mode, hold down SW1 and power cycle the kit until the blue LED (D1) is illuminated. To put the kit into Mass Storage Device (MSD) mode, do the same process with SW2 until pink LED is illuminated. Table 2 summarizes when SW1 and SW2 are used.

Table 2. Push Button Control with SW1 and SW2.

SW1 SW2

Speaker volume up Speaker volume down

OTW update mode MSD mode

3. Local Voice Control Engine

The flagship feature of the SLN-LOCAL-IOT is the bundled voice control engine, also referred to as ASR. NXP’s offering is a lightweight engine designed specifically for MCUs. It supports various use cases including wake word + command, “push to talk”, and even parallel instances of the ASR configured to listen for different command sets. The engine is event-based and relies on callbacks to tie in with the main application.

3.1 Project Assets The ASR requires three configuration items from the developer: a wake word model, a commands model, and a dialogue specification. The wake word model determines which wake word to listen for and the commands model determines which commands can be recognized. The list of recognizable commands is called the vocabulary. The dialogue is tied to the commands model as a dialogue depends on the vocabulary.


14

The wake word model, commands model, and dialogue specification will be auto-generated for the developer by NXP. These assets are to be placed in the assets folder of your project. The dialogue can be modified by the developer should it need to be adjusted. Lastly, the wake word and commands models are provided as binary blobs as C arrays.

3.2 Session Flow A dialog is made up of three concepts: intents, slots, and triggers. An intent is the final output of an interaction and is composed of a list of slots. A slot is like a variable that can take one value out of a list of values from the vocabulary. A trigger is a command from the vocabulary that will start the process of filling in an intent.

Figure 7. ASR Session Flow.

For example, we can consider a washing machine. A possible intent could be a description for the kind of wash cycle the user would like. One slot could be the temperature of the wash and the values could be “hot”, “cold”, and “warm”. Another slot could be the soil level with values of “heavy” and “light”. A trigger could be “warm wash”, which would cause the ASR state machine to request only the soil level slot because the temperature slot is implicit. Another trigger for this intent could be “custom wash” where none of the slots are implicitly filled in and must be filled in via interaction with the user.

The state machine of the ASR is described in Figure 7.


15

A session is defined as every state except for when waiting for the wake word. Note that any of the callbacks may return kSlnLocalCommandsSessionStop, at which point the

ASR would return to the wake word state. The Waiting Slot state may be skipped if the intent has no slots. Please note that in either the Waiting Trigger or Waiting Slot states, the user may request to cancel/end the session. In this case the ASR would jump to the Recognition Terminated state.

3.3 Dialogue Configuration The structure of the ASR session flow is configured and determined by the sln_local_commands_dialgoue_t structure passed in to SLN_LocalCommandsInit().

This object determines the intents, including which triggers are valid and which slots are needed. The definition of the sln_local_commands_dialgoue_t structure is found in

sln_intelligence_toolbox_local.h. The structure has three main parts; the list of valid commands, the cancel command, and the list of intents. The list of valid commands is pointed to by the commands pointer and is determined by the corresponding commands model. All variables of type sln_local_commands_commands_idx_t are simply indices

into this list. The cancel command is such a variable; if it’s non-zero, it’s an index into the commands list indicating which command can be used by the user to cancel a session. The list of sln_local_commands_intent_config_t objects determines the available

intents. Each intent has a list of sln_local_commands_slot_config_t objects and a list

of sln_local_commands_trigger_t objects. Each

sln_local_commands_slot_config_t object determines a slot for an intent, and simply

lists the commands that are valid values for the slot. The sln_local_commands_trigger_t objects determine which commands can be used to

initiate the intent. The trigger indicates a command as well as a list of slots; this way different triggers can have different required slots. Most of the time, a static instance of the sln_local_commands_dialgoue_t will be

automatically generated from a higher-level specification, so there is typically no need to create an instance manually.

4. Getting Started with the MCUXpresso Tools

This section describes how to set up the MCUXpresso development environment for your SLN-LOCAL-IOT. If you don’t have MCUXpresso installed already, go to


16

www.nxp.com/mcuxpresso for information and a download link. You will need an NXP account to download the IDE. Please see the Prerequisites section for specific details on supported tool versions.

4.1 J-Link Debugger Segger J-Link is a recommended debugger for the SLN-LOCAL-IOT kit. Developers need to make sure that the installed J-Link software version is later than v6.60. The J-Link software and documentation pack for various operating systems can be downloaded from www.segger.com/downloads/jlink.

4.2 Starting MCUXpresso IDE for the First Time The first time you start MCUXpresso IDE, it will ask you to point to or create a workspace. MCUXpresso IDE is Eclipse-based, so if you’ve worked with Eclipse, you’ll understand the basics. If you’re unfamiliar with Eclipse, workspaces are “sandboxes” that can contain multiple projects. It’s suggested that when you create a workspace that you name it to something unique so that you know what it contains in the event you have multiple workspaces.

Figure 8. MCUXpresso IDE Workspace Creation.

4.3 Installing the SDK The SLN-LOCAL-IOT kit comes with a MCUXpresso SDK that is customized for the Solution. Due to the nature of it being a solution with special software IP, it is currently not available in the MCUXpresso SDK Builder on www.nxp.com/mcuxpresso.

http://www.nxp.com/mcuxpresso

http://www.segger.com/downloads/jlink

http://www.nxp.com/mcuxpresso


17

The SDK is a comprehensive set of software that includes everything you’ll need to develop with both the RT106L device and the specific hardware of the SLN-LOCAL-IOT. Components of the SDK include an RTOS, middleware (USB, TCP/IP), drivers (MCU and external components) and reference software. After you obtain the software package for the SLN-LOCAL-IOT, you need to install it into MCUXpresso IDE. In the package, the SDK is a ZIP file located in the sdk folder as shown in Figure 9.

Figure 9. SDK Package Location.

Drag and drop the “SLN-LOCAL-IOT.zip” file into the “Installed SDKs” tab at the bottom of the IDE shown in Figure 10.

Figure 10. Installed SDKs Tab.

4.4 Importing Projects The SDK allows you to import existing application examples as a development starting point. There are a handful of applications in the SLN-LOCAL-IOT SDK that show you how to use the included features and software IP. To import a project, select “Import SDK example(s)…” from the Quickstart pane in the lower left corner of the IDE.


18

Figure 11. Importing Existing SDK Project.

A list of all the installed board SDKs will be shown that have examples that can be imported. Select the sln_local_iot option and then proceed by selecting the next button.

Figure 12. Select SLN-LOCAL-IOT Board.

The import wizard will then display all of the applications that are available to import.


19

Figure 13. Select Project to Import.

Once the projects have successfully been imported, they will be listed in the project explorer and are ready to build and run. Continue to the Building and Programming section to learn how to build the applications.

4.5 Building and Programming As described in the Security Architecture section, the bootstrap is the first flash-resident application that runs. The bootstrap is a minimal FreeRTOS application that is responsible for image verification of the bootloader. If the i.MX RT106L’s HAB is enabled on the chip, the bootstrap is the signed and trusted firmware. It also manages the eXIP context that feature should be enabled. This firmware is designed to be fixed for the lifetime of the product since any corruption of this image will result in an unbootable and bricked device. The bootloader project is a second stage bootloader that manages signature verification and jumping into the main application (in this case, the local_commands_demo application). This application can be used as a foundation to enable additional bootloader functionality needed for the end product. This bootloader is also responsible for Mass


20

Storage Device (MSD) drag and drop and Over-The-Wire (OTW) Image updating. The bootloader is also responsible for validating OTW images via signature verification and creating additional crypto context in the case of encrypted execute in place (eXIP) being enabled.

THERE IS OVER-THE-AIR (OTA) CAPABILITY THAT IS CURRENTLY NOT SUPPORTED IN ANY OF THE DEMO APPLICATIONS, THOUGH THE NECESSARY SOFTWARE COMPONENTS AND DRIVERS NEEDED TO ENABLE IT ARE AVAILABLE IN THE SDK

Lastly, the local_commands_demo is the main application and demonstrates the local voice control capabilities of the SLN-LOCAL-IOT. To build any of these projects, select the Build option in the Quickstart pane.

Figure 14. Building an Application.

4.5.1 Changing Image Verification Configuration To make development easier, the SLN-LOCAL-IOT kit has image verification turned off by default. This allows developers to modify the various applications that run on the chip without needing to re-sign the binaries and update the FICA table. When moving to production, it is suggested that image verification be turned on. To turn on image verification, there is a single macro change required. Verification is application-specific, so if the entire security chain must be enabled, the setting must be updated in both the bootstrap and bootloader applications. Right click on either the bootstrap or bootloader project in your workspace or, when the project is selected, navigate to Properties -> C/C++ Build -> Settings -> Preprocessor. Inside the Preprocessor section, change the DISABLE_IMAGE_VERIFICATION macro from ‘1’ to ‘0’ as shown in Figure 15 and Figure 16.


21

Figure 15. Enable Image Verification in the Bootstrap.

Figure 16. Enable Image Verification in the Bootloader.

After changing the macro, select the Build option in the Quickstart pane to rebuild the application.

Figure 17. Re-build Application.


22

4.5.2 Programming the SLN-LOCAL-IOT With the bootstrap, bootloader and local_commands_demo all compiled, it’s now time to program them into the flash. This section assumes that you have either turned off image verification or the firmware has already been signed as described in the image signing section. First, make sure that your J-Link probe is attached to your PC and that you have the J-Link driver greater than v6.60. Next, click on the project that you want to load onto your board and debug. Lastly, click on the Debug button in the Quickstart pane.

Figure 18. Start a Debug Session.

Select the J-Link probe that is connected to the board and press OK.

Figure 19. Probe Selection Dialogue.


23

This will launch the flashing tool and proceed to load the image into the flash. When this is complete, the debugger will be launched and running. You can then step, run or set breakpoints.

Figure 20. J-Link Programming Window.

4.5.3 Restoring Factory Settings With so many pieces in the memory map, it is possible that something can go wrong during development. NXP provides the full 32 MB application binary for the out-of-box demo as part of the software package for the SLN-LOCAL-IOT. Programming this binary onto your kit will erase the entire flash and replace it with the factory settings. To restore your SLN-LOCAL-IOT kit to the factory state, use the built-in flash programmer in MCUXpresso IDE. The flash tool can be opened by selecting the icon in the image shown in Figure 21.

Figure 21. Opening the GUI Flash Tool.

This will open the probe window as shown in Figure 22 which is the same window used for programming and debugging the board. After selecting OK, the GUI Flash Tool will pop up as displayed below.


24

Figure 22. GUI Flash Tool Window.

The Flash GUI Tool will automatically fill in the fields associated with the project that is currently selected. Select the “Filesystem” button to open a file selection window and select the local_commands_demo_full32mb.bin file from the binaries folder of the SLN-LOCAL-IOT software package. You might need to change the file extension type to “*.bin” to select the file.

Figure 23. Select the Binary.


25

Now, you need to specify the base address for the file you want to program. In the “Base Address” field, change the address to 0x60000000 to select the base address of the flash. Clicking on Run… will kick off the programming operation.

PROGRAMMING CAN TAKE UP TO 10 MINUTES DEPENDING ON YOUR PC SPECIFICATIONS AND PROBE SINCE THE BINARY IS 32 MB IN SIZE.

Figure 24. Programming Status Dialogue.

5. Bootloader

The SDK provided enables two forms of firmware update capability: an over-the-wire (OTW) interface that supports UART and a USB Mass Storage Device (MSD) interface. Either option can be selected at boot time, but once one of them is running, the other is turned off. Note that the firmware update in bootloader is only for the main application, not for the bootstrap and bootloader. If the bootstrap or bootloader needs to be updated, please use J-Link probe.

5.1 Application Flow The boot flow is described in detail in the Security Architecture section of this document. Once the boot flow reaches the bootloader, it has to decide what to do. Figure 25 shows the three options available to the bootloader. The subsequent sections describe the OTW and USB MSD modes.


26

Figure 25. Bootloader Flow.

5.2 Application Memory Banks There are two application banks in the flash memory on the SLN-LOCAL-IOT kit.

• Address for Application Bank A: 0x60300000

• Address for Application Bank B: 0x60D00000

Developers must configure the bank address properly when the main application is compiled. This ensures that the device is safe to jump into a new application image in one memory location without compromising the other one. If the application currently running is in Bank A, the new image must be linked to Bank B. To change the address from Bank A to Bank B, in the MCUXpresso IDE project explorer, right click on the sln_local_iot_local_commands_demo (or, the user’s application project name) > Project Settings > Memory, as shown in Figure 26. Select Edit Memory which will open the Memory Configuration Editor. Change the address of Flash type to 0x6030 0000 for Application Bank A and 0x60D0 0000 for Application Bank B.


27

Figure 26. Edit Memory Configuration.

Before building the application, users need to make sure that the MCUXpresso project generates a .bin file as an outcome of the build process. Right click on the project name and open Properties, as shown in Figure 27.

Figure 27. Project Properties.


28

Expand C/C++ Build in the menu and click Settings. Select Build steps tab where Post-build steps can be edited. Click Edit and it will show the commands for the Post-build steps. Figure 28 illustrates how to open the Post-build steps window.

Figure 28. Editing Post-build Steps.

A command character “#” disables all following commands. In order to generate .bin file in post-build process, remove the character “#” and click OK. The resulting commands must look like Figure 29 after removing “#”:


29

Figure 29. Post-build Commands to Generate .bin File.

If the build process is done successfully, a .bin file is generated and placed in Debug folder of the MCUXpresso Project.

5.3 Over-the-Wire (OTW) Update The OTW update interface currently supports UART but can be extended to support any serial interface including SPI, TCP sockets or even I2C. The OTW update is driven using a simple JSON interface, making it easy to implement host side code. NXP provides OTW update tools which are currently intended as a unit test. These tools in the current release are not intended to use for production environment.

5.3.1 Entering OTW Update Mode The bootloader first checks whether the kit enters MSD mode or OTW mode or jumps to the main application. The MSD mode will be described in the next section. While booting the kit, if the SW1 is pressed, the bootloader enters the OTW mode. There is another way to enter the OTW mode. The OTW mode can be triggered by receiving a command via host control interface such as the eRPC based SLN-LOCAL-IOT host control interface or a generic serial terminal. If the kit does not enter MSD or OTW mode, it jumps to the main application.


30

5.3.1.1 Triggered by SW1 The OTW update mode can be triggered by pressing SW1 while booting the kit. The blue LED on the kit will be illuminated and start waiting for UART incoming messages. Note that the USB CDC is connected to the kit already supplying the power as well as the serial communication. In order to run OTW via UART, it requires to have an additional UART module connected to J26 on the kit. Make sure the TX, RX, Vcc, and GND are connected properly.

Figure 30. Serial Port Header - J26.

5.3.1.2 Via eRPC based SLN-LOCAL-IOT Host Control Interface The eRPC based SLN-LOCAL-IOT host control interface currently supports only for Linux. Developers are recommended to review README.md prior to execute the host interface. The software application can be obtained from the download software package. When the kit is in OTW update mode, the blue LED on the kit will be illuminated and start waiting for UART incoming messages.

5.3.1.3 Via a Serial Terminal The kit can enter the OTW mode by typing “updateotw” command via Shell on a serial terminal, as shown in Figure 31.

Figure 31. OTW command via Shell.


31

When the kit is in OTW update mode, the blue LED on the kit will be illuminated and start waiting for UART incoming messages.

5.3.2 Unit Test via UART A firmware update test example is included in the bootloader project that was imported into MCUXpresso IDE in Section 4.4. The test example requires to install 1) Python 3.6 or greater, 2) PySerial, and 3) libscrc. Open fwupdate_client.py under unit_tests folder in sln_local_iot_bootloader MCUXpresso project. Then, edit the COM_PORT to match the target com port address that can be found in device manager of Windows. Make sure the port number in “/dev/ttyS0,” as shown in Figure 32.

Figure 32. Editing the COM_PORT in fwupdate_client.py.

5.3.3 Transfers Each transfer contains two pieces: a 4-byte size field and a JSON message. This allows the OTW data interface to be compatible across a wide range of interfaces.

Figure 33. Transfer Format.


32

Each transfer is followed by a transfer response.

Figure 34. Request / Response Flow.

5.3.4 JSON Messages The OTW interface is driven entirely by JSON messages. This allows developers to easily create and debug client applications. There are two types of messages passed: requests and responses. Requests must be made in the following order to successfully perform a firmware update:

1. Start 2. Block 3. Stop 4. Activate image 5. Start self-check. 6. Clean

5.3.4.1 Start Request This is the first request that must be sent to start a firmware update. {

"messageType":1,


33

"fwupdate_message": {

"messageType":0,

"fwupdate_common_message": {

"messageType":0,

"job_id": <Job ID string>,

"app_bank_type": <Flash Bank: ‘1’ for A ‘2’ for B>,

"signature": <RSA Signature of image to be loaded>,

"image_size": <Image Length>,

}

}

}

5.3.4.2 Block Request Block requests are sent for each “chunk” of data to be programmed. Block sizes can be any size, though it’s suggested that they be as large as possible. The example script in the SDK sends 4096 bytes per block request. {

"messageType":1,


"messageType":1,

"fwupdate_server_message": {

"messageType":0,

"block": <Base64 encoded block of data>,

"encoded_size": <Size of encoded block>,

"block_size": <Size of block in bytes>,

"offset": <Offset from base of flash>,

}

}

}

5.3.4.3 Stop Request {

"messageType":1,


"messageType":1,


"messageType":1

}

}

}

5.3.4.4 Activate Image Request


34

{

"messageType":1,


"messageType":1,


"messageType":3

}

}

}

5.3.4.5 Start Self-Test Request {

"messageType":1,


"messageType":1,


"messageType":2

}

}

}

5.3.4.6 Clean Request {

"messageType":1,


"messageType":0,

"fwupdate_common_message": {

"messageType":2

}

}

}

5.3.4.7 Response Format {

"error": <Operation return code>,

}

5.4 USB Mass Storage Device (MSD) Update The bootloader application supports firmware update over USB Mass Storage Device (MSD). This allows the user to re-flash the main application binary (note, not the bootstrap


35

and bootloader) without a J-Link probe. If the bootstrap and bootloader need to be updated, you must use the J-Link probe. The MSD feature by default bypasses signature verification to allow an easier development flow as signing images can be a process not suitable for quick debugging and validation. To put the device into MSD mode, hold down switch 2 (SW2) and power cycle the board until the pink LED (D1) is illuminated. the pink LED will turn on and off in 3 second intervals.

Figure 35. MSD Update Mode LED.

Navigate to the PC’s file explorer and confirm that the SLN-LOCAL-IOT kit is mounted as a USB mass storage drive. A mounted kit is displayed on the file explorer as shown in Figure 36.

Figure 36. SLN-LOCAL-IOT Kit Mounted as a USB Mass Storage Drive.

Drag and drop the generated .bin file onto the MSD drive. This will start the download process and write the .bin file to flash. After the image has been programmed into flash, it will begin to execute.


36

6. Automated Manufacturing Tools

NXP provides a package of scripts that can be used for securely programming devices on the production line. This collection of scripts is called Ivaldi.

6.1 About Ivaldi NXP provides a Factory Automation Environment that can be used for securely programming devices on the production line. This collection of scripts is called Ivaldi. Ivalidi is a package that is responsible for manufacturing programming and reprogramming without needing J-Link. It uses the serial downloader mode of the i.MX RT106L’s boot ROM to communicate with an application called Flashloader that is programmed into the RT106L. Ivaldi was created to focus on the build infrastructure of a customer’s development and manufacturing cycle. Its primary focuses are:

• Factory programming and device set up

• Enabling High Assurance Booting (HAB) and Encrypted eXecute In Place (eXIP)

• Signing images for Application Bank A or Bank B

• Writing and accessing One Time Programmable (OTP) fuses

6.2 Requirements and Setup The following requirements must be satisfied to run Ivaldi. It has been tested in Windows, Mac and Linux environments.

• OpenSSL

• Python 3.6.x with virtualenv

• Linux/Ubuntu for Windows The package contains valuable README files. To set up the environment, follow the README.md file located in the root folder of the Ivaldi package. Without doing this, the tool will not work. The Ivaldi tools are located in the Tools folder of the software package. Extract the ZIP file and open the README.md to start using the tool.

6.3 Creating a Signing Entity The Ivaldi tools provided by NXP require signing, so the end user must create their own CA and signing artifacts. For information about the chain of trust used by NXP from the factory, please refer to Section 2.4.1.


37

6.3.1 Using Ivaldi to Generate Signing Artifacts Ivaldi includes a script to generate all of the artifacts needed to properly sign application binaries and generate a FICA table. Prior to running the script, the Ivaldi environment must be set up completely as described in the README.md in the top-level directory. In the Python virtual environment, navigate to Scripts/ota_signing. Run the generate_signing_arfifacts.py script. When running without any arguments, the usage will be displayed.

Figure 37. Signing Artifact Generation Usage.

Type in a CA name (e.g., my_test_ca) and the rest of the information for the CA. When prompted for passwords for the PEM files, use the same password for all of them for this exercise. Developers can always re-generate a more secure CA when preparing for production. Figure 38 shows an excerpt from the terminal output of the generation script.

Figure 38. Signing Artifact Generation Excerpt.

Reference the README.md in the Scripts/ota_signing folder for more details about the directory structure and files that were generated by the script. Now we need to create filesystem-compatible binaries of the application signing certificate and CA certificate. To do this, we run the generate_image_crt_files.py script. Be sure to pass in the name of the generated CA on the command line.

Figure 39. Generation of Certificate Binaries.


38

The output of this script is two binary files in the Scripts/ota_signing folder. Copy these files to the Image_Binaries folder of the Ivaldi package as they will be programmed onto the SLN-LOCAL-IOT kit.

6.3.2 Open Boot Programming The Open Boot Programming tool is responsible for setting up and programming a device with the correct binaries, certificates and artifacts. This method is a quick and easy way of taking a device/product that has come from the assembly line and getting it ready to ship. It is also good practice to run the Open Boot Programming script before enabling the security features to ensure all images and artifacts are in working order. It is recommended to enable the security features which are detailed in the Enabling Encrypted Execution in Place (eXIP) and High Assurance Boot (HAB) section. Before running the Open Boot script, the appropriate binaries need to be placed in the Image_Binaries folder. All of the factory binaries (minus the user-specific certificate binaries) are included in the software package in the binaries/for_ivaldi folder. Copy the contents of this folder into the Image_Binaries folder of the Ivaldi tools. With the certificate binaries, your Image_Binaries folder should look like Figure 40.

Figure 40. Image_Binaries Folder Contents.

Next, the open_prog_full.py script (located in Scripts/sln_local_iot_open_boot) can be updated to program the desired locations (if not doing default). The default configuration of the script is designed for the local_commands_demo application that ships from the factory. For reference, the operations performed by the script are highlighted in comments in the main function. Change directory to Scripts/sln_local_iot_open_boot. To run the open_prog_full.py script, we must pass in the name or our CA (again, my_test_ca in this example). The output of the script will look similar to Figure 41.

BEFORE RUNNING THE SCRIPT, POWER DOWN THE KIT AND MOVE THE JUMPER ON J27 TO THE “0” POSITION. WHEN THE KIT IS TURNED ON, IT WILL BE IN SERIAL DOWNLOAD MODE.


39

When running this script, developers will be prompted for two passwords: one for the signing certificate PEM file and another for the CA PEM. Enter the password that was used when creating the CA.

Figure 41. Output of Ivaldi Open Boot Programming.


40

6.4 Enabling Encrypted Execution in Place (eXIP) and High Assurance Boot (HAB)

The i.MX RT106L has some fundamental security enablement to protect against unsigned images and ensure the integrity of high value software running on the device. These security features can be looked into at great detail by reading the i.MX RT1060 reference manual or a white paper related with security aspect of i.MX RT processor. In this section we explain the implementation steps to enable eXIP and HAB security features of the i.MX RT processor for SLN-LOCAL-IOT by using Python scripts. The bootstrap will be signed to work with the HAB and the bootloader and local_command_demo will be encrypted with individual encrypted context. The reason why the bootloader and local_command_demo have individual encrypted contexts is to ensure not to update the bootloader unnecessarily even if any of the application banks are updated. The secure boot Python scripts are separated in two folders:

• OEM – The scripts should only be executed by the Product Owner, and the output has to be stored in a secure environment. This is because it contains important key information, which if lost, could brick the SLN-LOCAL-IOT kits or be open to loss of image integrity. The example scripts are for demonstrating how to configure Public Key Infrastructure (PKI) and generate a secure binary.

• MANF – The scripts will be executed on the manufacturing line. They are used to execute the signed flashloader and communicate with the chip to encrypt the binaries. The scripts are intended to serve as examples for production line programming. Note that the script to enable HAB should only be performed once per device with known PKI (i.e., certificates and keys).

This process has several failure points, if you are not fully educated on the device. Some of these features are one-way and will permanently impact the behavior of the i.MX RT106L MCU. For additional information about the Ivaldi tool’s eXIP and HAB enablement, please build the documents in Ivaldi/doc folder by following the containing README.md file.

6.4.1 Generating the PKI and Signed Flashloader This section assumes that section 6.3 has been completed as it is needed to generate the CA and application certificate that will be loaded into the flash. It will also be used to generate the FICA table used to validate the application signature. The first step is to create a signed Flashloader which will be used to set everything up and communicate with blhost. The blhost tool in its simplest form is used to read and write registers but it communicates with a Flashloader. Flashloader is a RAM based

https://www.nxp.com/webapp/Download?colCode=IMXRT1060RM




41

application that supports the blhost communication. In normal circumstances, Flashloader can be executed without having been signed, but as HAB is going to be enabled, it needs to be signed with keys generated. The script setup_hab.py is to create PKI infrastructure and signed flashloader. It is highly recommended to review the README.md file before executing the script. The script and README.md are located under Scripts/sln_local_iot_secure_boot/oem” folder of the Ivaldi manufacturing tool. The script setup_hab.py will generate the signed Flashloader with the file name ivt_flashloader_signed.bin and ivt_flashloader_signed_nopadding.bin in the Image_Binariy folder. The other output of setup_hab.py is the PKI. The certificates and keys are generated in the crts and keys folder. Please note, do not run setup_hab.py more than once without backing up the generated keys and certificates. This will result in being unable to use Flashloader and program new images via serial download mode for existing HAB enabled devices.

6.4.2 Creating the Images We describe how to generate images, prior to creating the artifacts and loading them into the encrypted devices. Since the Instruction Vector Table (IVT) is created by the Ivaldi scripts, we need to configure the bootstrap project before creating the image. To do this, right click on the bootstrap project and navigate to Properties > C/C++ Build > Settings > Preprocessors, and as shown in Figure 42, set XIP_BOOT_HEADER_ENABLE and XIP_BOOT_HEADER_DCD_ENABLE to zero.

Figure 42. Unsetting of the XIP Boot Header.


42

After these definitions are updated, build the bootstrap project to generate an image. As the Ivaldi script only accepts srec file format, use the MCUXpresso Binary Utilities to convert .axf to .srec in the bootstrap project. Right click on the .axf file and then navigate Binary Utilities > Create S-Record.

Figure 43. Converting to .srec File.

Figure 44. Changing from .s19 to .srec.

As this creates an .s19 file, rename the file to .srec as shown in Figure 44. Continue to build the bootloader and local_command_demo projects in the usual way. When these applications are built, it is required to generate .bin files. Build these by navigating to the Debug folder in both the bootloader and local_command_demo application projects. Right click on the .axf file and navigate Binary Utilities > Create Binary.


43

Once the collateral has been created, copy the .bin and .srec files into Image_Binaries folder.

6.4.3 Generating Secure Binary We explain how to create a secure binary in preparation to programming it into the flash of the kit. Navigate to Scripts/sln_local_iot_secure_boot/oem folder and open secure_app.py. Inside this file contains the path and the file names of the binaries that will be used to create the secure binary as shown in Figure 45. Make sure that the actual files exist and the file names are correct.

Figure 45. Secure App File Names.

Execute secure_app.py to generate the encrypted image (boot_crypt_image.sb) as well as signed bootstrap (sln_local_iot_bootstrap.signed.bin). With an option “—signed-only,” we can generate the signed image (boot_sign_image.sb).

6.4.4 Enabling High Assurance Boot (HAB) HAB is a feature of the i.MX RT106L that forces the Read Only Memory (ROM) to only boot into a signed image. This ensures image integrity and prevents physical and remote attacks from power on. To execute the following steps, move the jumper J27, which is located on the top of the SLN-LOCAL-IOT kit into the “0” position. If running eXIP, move the jumper J27 (Encryption Boot Configuration Jumper), which is located at the back of the kit near the JTAG header into the position closest to the JTAG. To enable HAB on i.MX RT106L, we need to use the PKI and the signed flashloader generated in Section . If the signed Flashloader and certificates / keys are lost, the SLN-LOCAL-IOT kit will no longer be functional, as HAB ensures only signed images can boot.


44

Navigate to the Scripts/sln_local_iot_secure_boot/manf and execute enable_hab.py python script to enable HAB.

6.4.5 Enabling and Programming the Signed and Encrypted Binaries This section assumes that section 6.3 has been completed as it is needed to generate the CA and application certificate that will be loaded into the flash. It will also be used to generate the FICA table used to validate the application signature. Encrypted Execution in place (eXIP) is a feature of the i.MX RT106L that enables the chip to execute and decrypt on the fly allowing images to be store into external flash encrypted uniquely per part. This gives product makers safe comfort that their IP is protected, and physical attacks aren’t possible. It also means that the device cannot have malicious firmware programmed into it that can be executed as the device would fail with an encryption error. If the security of the device was compromised, it would also mean that the firmware they are able to obtain cannot be programmed into another device due to the unique nature of the encryption. The ”prog_sec_app.py” Python script conducts the followings:

• Runs the signed Flashloader for configuration

• Erase the current flash

• Programs the following o Signed bootstrap o Encrypted / Unencrypted bootloader and local_command_demo o Solution intelligence toolbox o Application image signing certificate o CA image certificate o Device key and certificate

7. Filesystem

The SLN-LOCAL-IOT has implemented a custom file system to manage files on-chip. The reasons a custom file system was chosen are:

1. The device executes code from flash (XiP) which means it needs to read flash from RAM functions.

2. HyperFlash has 256 KB sector sizes which doesn’t allow granularity of files. 3. Update in-place features are added to allow the updating of a big sector without a

costly (in time) erase. Within Ivaldi, there is a script that converts any file into a filesystem-compatible binary file. Any file that gets programmed to the filesystem must first pass through this script. This script is called file_format.py and is located in Scripts/sln_local_iot_utils.


45

Figure 46. Running file_format.py.

7.1 Generating New WAV Files As mentioned in the previous section, any file that gets stored in the filesystem must first be run through the file_format.py script. This means that updating any sound files that will be played back through the speaker must be in a filesystem-compatible format. Prior to generating the binary files, simply create 16-bit 48 kHz WAV files of your desired sounds. The current configuration of the amplifier only supports 48 kHz playback – not 16 kHz.

THE CUSTOM FILESYSTEM FOR HYPERFLASH LIMITS ITS SIZE TO 256KB PER FILE THAT INDLCUES FILE HEADER AS WELL AS SOUND DATA. THEREFORE, MAKE SURE THE GENERATED BINARY FILE SIZE IS LESS THAN 256KB.


46

8. References

The following references are available to supplement this document:

• SLN-LOCAL-IOT-UG, Solution User’s Guide

• Hardware files (Gerbers, schematics, BOM)

9. Revision History

Revision Date Changes

0 10/2019 Initial Release for alpha 1.0

1 01/2020 Updates for beta preRC release.

1.1 02/2020 Updates for global launch.

10. Acronyms

Acronym Meaning (Definition)

AFE Audio Front End

ASR Automatic Speech Recognition

CA Certificate Authority

FTDI Future Technology Devices International

FICA

Flash Image Configuration Area

Memory space of the external Flash that contain information about binary images of application and bootloader stage.

GUI Graphic User Interface

HAB High Assurance Bootloader

IOT Internet Of Thing

IVT Instruction Vector Table

JTAG Joint Test Action Group

MANF Manufacturer

MCU Microcontroller Unit

MEMS Micro-Electro-Mechanical System

MSD Mass Storage Device

OEM Original Equipment Manufacturer

OTW Over The Wire

OTP One Time Programmable

PCM Pulse-code modulation


47

PDM Pulse-density modulation

PKI Public Key Infrastructure

ROM Read Only Memory

RTOS Real-Time Operating System

SDK Software Development Kit

UART Universal asynchronous receiver-transmitter

(e)XIP (encrypted) eXecute In place


48

How to Reach Us:

Home Page:

www.nxp.com

Web Support:

www.nxp.com/support

Information in this document is provided solely to enable system and software

implementers to use NXP products. There are no express or implied copyright licenses

granted hereunder to design or fabricate any integrated circuits based on the information

in this document. NXP reserves the right to make changes without further notice to any

products herein.

NXP makes no warranty, representation, or guarantee regarding the suitability of its

products for any particular purpose, nor does NXP assume any liability arising out of the

application or use of any product or circuit, and specifically disclaims any and all liability,

including without limitation consequential or incidental damages. “Typical” parameters that

may be provided in NXP data sheets and/or specifications can and do vary in different

applications, and actual performance may vary over time. All operating parameters,

including “typicals,” must be validated for each customer application by customer’s

technical experts. NXP does not convey any license under its patent rights nor the rights

of others. NXP sells products pursuant to standard terms and conditions of sale, which can

be found at the following address: www.nxp.com/SalesTermsandConditions.

NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD,

Freescale, the Freescale logo are trademarks of NXP B.V. All other product or service

names are the property of their respective owners. Arm, AMBA, Arm Powered, Artisan,

Cortex, Jazelle, Keil, SecurCore, Thumb, TrustZone, and μVision are registered

trademarks of Arm Limited (or its subsidiaries) in the EU and/or elsewhere. Arm7, Arm9,

Arm11, big.LITTLE, CoreLink, CoreSight, DesignStart, Mali, Mbed, NEON, POP,

Sensinode, Socrates, ULINK and Versatile are trademarks of Arm Limited (or its

subsidiaries) in the EU and/or elsewhere. All rights reserved.

© 2019 NXP B.V

http://www.nxp.com/

http://www.nxp.com/support

http://www.nxp.com/SalesTermsandConditions

Date post:	07-Oct-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

Developer Guide - MCU Local Voice Control Kit · on the high performance i.MX RT106L...

Documents