Jump To
Quick Reference
- Chip Documents
1. Out of the Box
The following section describes the steps to boot the i.MX7Dual Sabre.
Development Kit Contains:
- i.MX7Dual Sabre board for smart devices
- USB cable (micro-B to standard-A)
- Cable -Assembly, USB 3.0 Type-A Male, USB micro-B Male, Shielded, 1m
- 5V/5A universal power supply
- Quick Start Guide
- 8 GB SD Card with bootable operating system demonstration image
1.1 Get Familiar with the Board
Figure 1. i.MX7Dual Sabre front
Figure 2. i.MX7Dual Sabre back
1.2 Insert the SD Card (SD1/J6)
The kit includes an SD card with a pre-built NXP Linux binary demo image. Without modifying the binary inside the SD card, booting from this SD card provides a default system with certain features for building other applications on top of Linux. The software is described in the following sections.
1.3 Connect USB Debug Cable
Connect the micro-B end of the supplied USB cable into Debug UART port J11. Connect the other end of the cable to a host
computer.
If you are not sure about how to use a terminal application, try one of the following tutorials depending on the operating system of the host machine:
Linux
Windows
Windows
Connect the HDMI cable
To see the user interface provided with the SD card image binary connect a monitor via the HDMI connector
(J9).
1.5 Boot Switch Setup
Click here to see the Boot Switch Setup
1.6 Connect Power Supply
Connect the 5V power supply cable to the 5V DC power jack (J1).
Power the board by flipping the switch (SW1). The
processor starts executing from the on-chip ROM code. With the default boot switch setup, the code reads
the fuses to define the media where it is expected to have a bootable image. After it finds a bootable
image on the SD card, the U-Boot execution should begin automatically.
Information is printed in the smaller number serial console for the Cortex-A7 (COM9 on Windows as an example and /dev/ttyUSB* on Linux). If you don not stop the U-Boot
process, it continues to boot the Linux kernel.
On Windows as an example
1.7 Congratulations! Linux® has booted!
Once Linux is booted, login using the user name root
and no password.
Tip: To proceed to U-Boot, press any key before the value of the U-Boot environment
variable, bootdelay, decreases and before it times out
(default 3 seconds). If you stop the U-Boot process, you can run the following command to continue with
the Linux boot process:
# bootMinicom Tutorial
Serial communication console setup
On the command prompt of the Linux host machine, run the following command to determine the port number:
$ ls /dev/ttyUSB*
The smaller number is for Cortex-A7 and the bigger number is for Cortex-M4.
Minicom
Use the following commands to install and run the serial communication program (minicom as an example):
- Install Minicom using Ubuntu package manager.
$ ls /dev/ttyUSB* - Launch Minicom using a console window using the port number
determined earlier.
$ sudo minicom /dev/ttyUSB* -s - Configure Minicom as show in [Minicom Configuration]
- The next step is to [Connect the HDMI cable].
Figure 3. Minicom Configuration
Tera Term Tutorial
Serial communication console setup
The FTDI USB-serial chip on i.MX7Dual enumerates two serial ports. Assume that the ports are COM9 and COM10. The smaller numbered port (COM9) is for the serial console communication from Cortex-A7 and the larger numbered port (COM10) is for Cortex-M4. The serial-to-USB drivers are available at http://www.ftdichip.com/Drivers/VCP.htm.
Note: To determine the port number of the i.MX board virtual COM port, open the Windows device manager and find USB serial Port in Ports (COM and LPT)
Teraterm
Is an open source terminal emulation application. This program displays the information sent from the NXP development platform’s virtual serial port.
- Download Tera Term. After the download, run the installer and then return to this web page to continue.
- Launch TeraTerm. The first time it launches, it shows the following dialog. Select the serial option. Assuming your board is plugged in, there should be a COM port automatically populated in the list.
- Configure the serial port settings (using the COM port number identified earlier) to 115200 baud rate, 8 data bits, no parity and 1 stop bit. To do this, go to Setup → Serial Port and change the settings.
- Verify that the connection is open. If connected, Tera Term shows something like below in its title bar.
- The next step is to [Connect the HDMI cable].
PuTTY Tutorial
Serial communication console setup
The FTDI USB-serial chip on i.MX7Dual enumerates two serial ports. Assume that the ports are COM9 and COM10. The smaller numbered port (COM9) is for the serial console communication from Cortex-A7 and the larger numbered port (COM10) is for Cortex-M4. The serial-to-USB drivers are available at http://www.ftdichip.com/Drivers/VCP.htm.
Note: To determine the port number of the i.MX board virtual COM port, open the Windows device manager and find USB serial Port in Ports (COM and LPT)
PuTTY is a popular terminal-emulation application. This program displays the information sent from the NXP development platform’s virtual serial port.
- Download PuTTY After the download, run the installer and then return to this webpage to continue.
- Launch PuTTY by either double clicking on the executable file you downloaded or from the Start menu, depending on the type of download you selected.
- Configure In the window that launches. Select the
Serial radio button and enter the COM port number that you
determined earlier. Also enter the baud rate, in this case
115200. - Click Open to open the serial connection. Assuming the board is connected and you entered the correct COM port, the terminal window opens. If the configuration is not correct, PuTTY alerts you.
- The next step is to [Connect the HDMI cable].
Embedded Linux®
This section is applicable ONLY if attempting to load a Linux operating system on the board.
The i.MX Linux Board Support Package (BSP) is a collection of binary files, source code, and support files that are used to boot an Embedded Linux image on a specific i.MX development platform.
Current releases of Linux binary demo files can be found on the i.MX Linux download page. The Linux User Guide and Linux Reference Manual provide additional information. Additional documentation can be found the i.MX Linux documentation bundle, or under the Linux sections on the i.MX Software and Development Tool.
2.1 Overview
Before the Linux OS kernel can boot on an i.MX board, the Linux image is copied to a boot device (SD card, eMMC and so on) and the boot switches are set to boot that device.
There are various ways to download the Linux BSP image for different boards and boot devices.
For this getting started guide, only a few methods to transfer the Linux BSP image to an SD card are listed. Experienced Linux developers can explore other options.
2.1.1. Download an NXP Linux BSP pre-built image
The latest pre-built images for the i.MX 8QuadMax MEK are available on the Linux download page. The file L4.14.78_1.0.0_ga_images_MX7DSABRESD.zip gathers every artifact required to boot the board.
The pre-built NXP Linux binary demo image provides a typical system and basic set of features for using and evaluating the processor. Without modifying the system, the users can evaluate hardware interfaces, test SoC features, and run user space applications.
When more flexibility is desired, an SD card can be loaded with individual components (boot loader, kernel, dtb file, and rootfs file) one-by-one or the .sdcard image is loaded and the individual parts are overwritten with the specific components.
2.1.2. Burn NXP Linux BSP image using UUU
In addition to the connections from Out of box chapter, connect the J25 to the host machine using the proper USB cable.
Turn off the board. Consult Boot switch setup and configure the board to boot on SDP (Serial Download Protocol) mode.
Depending on the OS used in the host machine, the way to transfer the Linux BSP image onto an SD card can vary.
Choose an option below for detailed instructions:
2.2 Linux
2.1.2.1. Install UUU on Linux Distro
Download the latest stable files from UUU GitHub page. An extensive tutorial for UUU can be found in https://github.com/NXPmicro/mfgtools/wiki.
- uuu
- libusb1 (via apt-get or any other package manager)
2.1.2.1.1. Burn the NXP Linux BSP image to the board
By default, this procedure flashes the image to the SD card flash. Check the UUU GitHub page for reference on how to flash the image to other devices.
Open a terminal application and change directory to the location where uuu and the latest Linux distribution for i.MX7Dual Sabre are located. Add execution permission to the uuu file and execute it. Uuu waits for the USB device to connect
$ chmod a+x uuu
$ sudo ./uuu L4.14.78_1.0.0_ga_images_MX7DSABRESD.zip
Turn on the board, uuu starts to copy the images to the board.
When it finishes, turn off the board, and consult Boot switch setup to configure the board to boot from SD card.
2.3 Windows
2.1.2.2. Install UUU on Windows
Download the latest stable files from UUU GitHub page. An extensive tutorial for UUU can be found in https://github.com/NXPmicro/mfgtools/wiki.
- uuu
- Serial USB drivers (depending on your board and Windows installation - check Windows Device Manager)
2.1.2.2.1. Burn the NXP Linux BSP image to the board
By default, this procedure flashes the image to the SD card flash. Check the UUU GitHub page for reference on how to flash the image to other devices.
Open the Command Prompt application and navigate to the directory where the uuu.exe file and the Linux release for the i.MX7Dual Sabre are located.
> uuu.exe L4.14.78_1.0.0_ga_images_MX7DSABRESD.zip
Turn on the board, uuu starts to copy the images to the board.
When it finishes, turn off the board, and consult Boot switch setup to configure the board to boot from SD card.
Embedded Android™
This section describes the boot process of loading the i.MX7Dual Sabre board with an Embedded Android system image and introduces how to build the software components that create your own system image. For details on building the Android platform, see https://source.android.com/source/building.html
The current release includes Demo Images, Source code and Documentation. These can also be found under Android section of the i.MX Software and Development Tool.
3.1 Overview
The storage devices on the development system (MMC/SD or NAND) must be programmed with the U-Boot boot loader. The boot process determines which storage device to access based on the switch settings. When the boot loader is loaded and begins execution, the U-Boot environment space is then read to determine how to proceed with the boot process.
The images can come from pre-built release packages or be created from source code. Regardless of how you obtain them, all Android images contain the following components:
-
U-Boot image:
u-boot.imx -
boot image:
boot.img -
Android system root image:
system.img -
Recovery root image:
recovery.img
For more information about the Android BSP refer to the Android User Guide.
Depending on the OS used in the host machine, the way to transfer the Android BSP image onto an SD card can vary.
3.1.1. Download NXP Android BSP image
The pre-built NXP Android demo image provides a default system with certain features for evaluation. Without modifying the system, users can perform some basic operations, and interact with the system to test hardware interfaces and develop software application in the user space.
The pre-built images from the package are categorized by boot device and put in the directory with the device name. The latest pre-built image files can be found in Android section on the i.MX Software and Development Tool, or on the demo images downloader link.
3.1.2. Burn NXP Android BSP image using UUU
In addition to the connections from Out of box chapter, connect the J25 to the host machine using the proper USB cable.
Turn off the board. Consult Boot switch setup and configure the board to boot on SDP (Serial Download Protocol) mode.
Choose an option below for detailed instructions:
3.2 Linux
3.1.2.1. Download UUU on Linux
Download the latest stable files from UUU GitHub page. An extensive tutorial for UUU can be found in https://github.com/NXPmicro/mfgtools/wiki.
- uuu
- libusb1 (via apt-get or any other package manager)
3.1.2.2. Download the latest Android images
Download the Android demo files from NXP.com.
Extract the downloaded file into a know directory.
3.1.2.3. Burn the NXP Linux BSP image to the board
By default, this procedure flashes the image to the SD card flash. Check the UUU GitHub page for reference on how to flash the image to other devices.
Copy the file named uuu from section Download UUU on Linux into the extracted Android demo directory.
Add execution permission to the uuu file and execute it. uuu waits for the USB device to connect
$ chmod a+x uuu
$ sudo ./uuu {UUU_ANDROID_FILE}
Turn on the board in serial download mode, uuu starts to copy the images to the board. To put the board in serial download mode follow the instructions on the Boot switch setup section.
When it finishes, turn off the board, and consult Boot switch setup to configure the board to boot from SD card.
3.3 Windows OS
3.1.3. Download UUU on Windows
Download the latest stable files from UUU GitHub page. An extensive tutorial for UUU can be found in https://github.com/NXPmicro/mfgtools/wiki.
- uuu
- Serial USB drivers (depending on your board and Windows installation - check Windows Device Manager)
3.1.4. Download the latest Android images
Download the Android demo files from NXP.com.
Extract the downloaded file into a know directory.
3.1.5. Burn the NXP Linux BSP image to the board
By default, this procedure flashes the image to the SD card flash. Check the UUU GitHub page for reference on how to flash the image to other devices.
Copy the file named uuu from section Download
UUU on Windows into the extracted Android demo directory.
Add execution permission to the uuu file and execute it. uuu waits for the USB device to connect
> uuu.exe {UUU_ANDROID_FILE}
Turn on the board in serial download mode, uuu starts to copy the images to the board. To put the board in serial download mode follow the instructions on the Boot switch setup section.
When it finishes, turn off the board, and consult Boot switch setup to configure the board to boot from SD card.
FreeRTOS™
This section describes how to load FreeRTOS for i.MX7Dual. FreeRTOS is an optional Real-Time Operating System (RTOS) which NXP uses to enable the Cortex-M cores in some of our products. Enabling the Cortex-M cores is an optional step. If you do not wish to enable the Cortex-M4 on i.MX7Dual at this moment you can skip this section.
The FreeRTOS BSP for i.MX7Dual is a suite of robust peripheral drivers and multicore communication mechanism designed to simplify and accelerate application development on the i.MX7Dual Processor.
Included in the FreeRTOS BSP for i.MX7Dual is full source code under a permissive open-source license for all demos, examples, middleware, and peripheral driver software.
4.1 Overview
The FreeRTOS BSP for i.MX7Dual consists of the following runtime software components written in C:
- Arm® Cortex Microcontroller Software Interface Standard (CMSIS) Core, DSP standard libraries, and CMSIS-compliant device header files which provide direct access to the peripheral registers and bits.
- A set of peripheral drivers that provides a simple, stateless driver with an API encapsulating register access of the peripheral.
- A multicore communication mechanism (RPMsg) to decrease the developing difficulty of multicore communication.
- A FreeRTOS operating system to provide an event triggered preemptive scheduling RTOS.
The demos/examples in FreeRTOS BSP are built for on-chip Tightly Coupled Memory (TCM) in the Arm® Cortex®-M4® core.
4.2 Download NXP FreeRTOS source and demos
Current releases of the NXP FreeRTOS BSP and source code can be found on the links below. There is option to download a self-extract installer that can be used on Windows OS, or a tarball for installation on Linux OS.
There are four main areas under the install directory of the FreeRTOS BSP tree used to provide the full source code for each demo application:
- The
examplesfolder contains all demos/examples source code and board configuration files. All 21 applications are cataloged by board name. - The
middlewarefolder contains the source code of all the middleware used by demos and examples. The open source multicore communication stack – RPMsg is included in the middleware folder. - The
platformfolder contains the source code for the primary components including CMSIS header files, peripheral drivers, startup, utilities, and linker files. - The
rtosfolder contains the source code of market leading RTOS – FreeRTOS OS.
The FreeRTOS BSP comes with rich demo applications and driver examples. To see what’s available,
browse the BSP examples folder and select the
i.MX7Dual Sabre board
(
To learn more about demo applications or driver examples, open the FreeRTOS i.MX7Dual Demo Application
User’s Guide, located in
If one or more of the demo applications or driver examples sounds interesting, you’re probably wanting to know how you can build and debug yourself. The Getting Started Guide with FreeRTOS BSP provides easy, step-by-step instructions on how to configure, build, and debug demos for all toolchains supported by the BSP.
Depending on the OS used in the host machine, the way to build and deploy the demos can vary.
Choose an option below for detailed instructions:
4.3 Build FreeRTOS on Linux
4.3.1 Install toolchain
-
Download and run the installer from
launchpad.net/gcc-arm-embedded. This is the actual toolchain. The toolchain includes the compiler, linker, and so on. The GCC toolchain should correspond to the latest supported version, as described in the FreeRTOS BSP Release Notes found in the package already downloaded. -
Export the toolchain location as
ArmGCC_DIR.$ export ArmGCC_DIR=/usr
Note:
/usris the usual install directory when youapt-get gcc-arm-none-eabi. Change the directory if this changes. -
Ensure that
cmakeis installed:$ sudo apt-get install cmake
$ sudo apt-get install gcc-arm-none-eabi
4.3.2 Build FreeRTOS demo applications
-
Change the directory of the command window to the demo
armgccdirectory and run the build command:$ cd
/examples/imx7d_sdb_m4/demo_apps/ /armgcc $./build_all.sh
-
There are two project configurations (build targets) supported for each FreeRTOS BSP project:
-
Compiler optimization is set to low, and debug information is generated for the executable. This target should be selected for development and debug.
-
Compiler optimization is set to high, and debug information is not generated. This target should be selected for final application deployment.
Debug
Release
Note: There are script files provided to build both configurations. For this example, the
Debugtarget is built andbuild_debug.shis typed on the command line. If theReleasetarget is desired, type thebuild_release.shinstead. -
-
The previous command generates the debug and release binaries (
.binfiles) to boot the Cortex- M4. These files are located in the debug and in the release directories. Copy one of these binaries to the boot partition of the SD card.
4.4 Build NXP FreeRTOS on Windows
4.4.1. Install toolchain
Download and run the installer from launchpad.net/gcc-arm-embedded. This is the actual toolchain. The toolchain includes the compiler, linker, and so on. The GCC toolchain should 20 correspond to the latest supported version, as described in the FreeRTOS BSP Release Notes found in the package already downloaded.
4.4.2 Install MinGW
The Minimalist GNU for Windows (MinGW) development tools provide a set of tools not dependent on third-party C-Runtime DLLs (such as Cygwin). The build environment used by the FreeRTOS BSP does not utilize the MinGW build tools, but does leverage the base install of both MinGW and MSYS. MSYS provides a basic shell with a Unix-like interface and tools.
-
Download the latest MinGW mingw-get-setup installer from: https://sourceforge.net/projects/mingw/files/Installer/
-
Run the installer. The recommended installation path is
C:\MinGW, however, you may install to any location.Note: The installation path cannot contain any spaces.
-
Ensure that the
mingw32-baseandmsys-baseare selected under Basic Setup.
Figure 13. MinGW files
-
Click
Apply Changesin theInstallationmenu and follow the remaining instructions to complete the installation.
Figure 14. Apply changes
-
Add the appropriate item to the Windows operating system Path environment variable. It can be found under Control Panel → System and Security → System → Advanced System Settings in the Environment Variables… section. The path is:
\bin Important: Assuming the default installation path,
C:\MinGW, an example is shown below. If the path is not set correctly, the toolchain does not work.
If you haveC:\MinGW\msys\x.x\binin yourPATHvariable (as required by KSDK 1.0.0), remove it to ensure that the new GCC build system works correctly. -
Create a new system environment variable and name it
ArmGCC_DIR. The value of this variable should point to the Arm GCC Embedded tool chain installation path, which, for this example, is:C:\Program Files (x86)\GNU Tools Arm Embedded\4.8 2014q3Reference the installation folder of the GNU Arm GCC Embedded tools for the exact path name of your installation.
Figure 15. Variable name
4.4.3 Install CMake
-
Download CMake 3.0.x from https://www.cmake.org/cmake/resources/software.html
-
Before installing CMake, ensure that the option Add CMake to system PATH is selected. It is up to the user to select whether it is installed into the PATH for all users or just the current user. In this example, the assumption is that it is installed for all users.
Figure 16. Install CMake
-
Follow the remaining instructions of the installer.
Note: You may need to reboot your system for the PATH changes to take effect.
4.4.4 Build a demo application
-
Open a GCC Arm Embedded tool chain command window. To launch the window, from the Windows operating system Start menu, go to Programs → GNU Tools Arm Embedded version> and select GCC Command Prompt.
Figure 17. GCC command prompt
-
Change the directory of the command window to the demo
armgccdirectory and run the build command:\examples\imx7d_sdb_m4\demo_apps\ \armgcc Or double-click on the
build_all.batfile in Explorer to perform the build. The expected output is shown in this figure:
Figure 18. Build result
-
There are two project configurations (build targets) supported for each FreeRTOS BSP project:
-
Compiler optimization is set to low, and debug information is generated for the executable. This target should be selected for development and debug.
-
Compiler optimization is set to high, and debug information is not generated. This target should be selected for final application deployment.
Debug
Release
Note:There are script files provided to build both configurations. For this example, the
Debugtarget is built andbuild_debug.batis typed on the command line. If theReleasetarget is desired, typebuild_release.batinstead. -
-
The previous command generates the debug and release binaries (
.binfiles) to boot the Cortex- M4. These files are located in the debug and in the release folders. Copy one of these binaries to the boot partition of the SD card.
4.5 Run applications using U-Boot
This section describes how to run applications using an SD card using pre-built U-Boot image for i.MX processor.
- Prepare an SD card with a pre-built U-Boot + Linux image from Linux BSP package for the i.MX7Dual processor following the steps on the Embedded Linux® tab. If you have already loaded your SD card with a Linux image you can skip this step.
- Insert the SD card to the your host computer (Linux or Windows), and copy the application image (for
example
hello_world.bin) that you want run to the FAT partition of the SD card. - Safely remove the SD card from the PC.
- Insert the SD card to the target board. Make sure to use the default boot SD slot and double check the Boot Switch Setup. The default configuration of the validation board boots from SD1/J6, and on Sabre board there is only one SD slot which is used for boot.
-
Connect the DEBUG UART slot on the board with your PC through the USB cable. The Windows OS installs the USB driver automatically, and the Ubuntu OS will find the serial devices as well.
See Serial Communication Console setup section in Out of the Box for more instructions for serial communication applications.
- Open a second terminal emulator on the i.MX7Dual Sabre board’s second enumerated serial port.
This is the Cortex-M4’s serial console. Set the speed to
115200bps, data bits8, no parity, and power on the board. -
Power up the board and stop the boot process by pressing any key before the U-boot countdown reaches zero. At the U-Boot prompt on the first terminal emulator, type the following commands to U-Boot.
-
=> fatload mmc 2:1 0x7F8000.bin -
=> dcache flush -
=> bootaux 0x7F8000
-
These commands copy the FreeRTOS memory image file from the first partition of the SD card into the Cortex-M4’s memory and releases the Cortex-M4 from reset.
Some applications with the names ended by ddr or ocram in FreeRTOS BSP should be run in DDR or OCRAM.
Those ended by qspi should boot from external QSPI
flash.
For additional instructions on how to boot from other storage, read section 6.2 and 6.3 in Getting Started with FreeRTOS found inside the package downloaded in section Download NXP FreeRTOS source and demos.
4.6 Example Demo
Demo and example applications are provided to demonstrate peripheral drivers, FreeRTOS kernel, RPMsg usage and to highlight the main features of the i.MX7Dual processor.
The FreeRTOS BSP provides two types of software applications:
- Demos: Applications intended to highlight key functions of the Arm® Cortex®-M4 Core in i.MX7Dual SoC, focusing on a particular use case on FreeRTOS OS.
- Examples: Simple applications intended to concisely illustrate how to use the peripheral drivers of the FreeRTOS BSP in the bare metal environment.
4.6.1 Cortex-M4 standalone sensor demo:
The Sensor Demo i.MX7Dual is a simple demonstration program that uses the FreeRTOS and a set of drivers provided by NXP. It can get the current gravitational acceleration, temperature, altitude and magnetic field strength of the board. The purpose of this demo is to show how to use the I2C driver as a Controller to communicate with other I2C Targets.
In the second terminal emulator for Cortex-M4, you should see text indicating the sensor example is running (e.g., below). Choose one of the sensor demos and affect the given sensor by moving the board or moving something magnetic near it.
-------------- iMX7D SDB on board sensor example --------------
Please select the sensor demo you want to run:
[1].FXAS21002 3-axes Gyro sensor
[2].FXOS8700 6-axes Acc+Mag sensor
[3].MPL3115 Pressure sensor
5.1 Explore the documentation
When working with embedded systems, it is important to bear in mind that the documentation is wide and diverse. It is common to have different levels of documentation. The i.MX7Dual Sabre board has some documents. However, this board’s processor is i.MX7Dual which is documented with SoC level documents. The BSPs available are documented with the BSP level documents.
Choose an option below for related documents:
5.1.1 Board documentation
In the case of i.MX7Dual Sabre the following documents are available.
Table 4. List of i.MX7Dual Sabre board-related documents
| Document | Description |
| Board Schematics | The i.MX7Dual Sabre electric schematic files. |
| i.MX7Dual Sabre Hardware User Guide | The purpose of this document is to help hardware engineers design and test their imx7d series processor-based designs. It provides information on board layout recommendations, design checklists to ensure first-pass success, and ways to avoid board bring-up problems. It also provides information on board-level testing and simulation such as using BSDL for boardlevel testing, using the IBIS model for electrical integrity simulation and more. |
5.2 Key features in Linux BSP
With Linux running on the i.MX board, you can evaluate special features that i.MX SoCs provide. This tutorial present the step-by-step for the following demos.
Choose an option below for detailed instructions:
5.2.1 Power management
This example shows how to suspend to low-power modes and resuming to normal operation.
-
Enter the command below in order to enable serial TTY as a wake up source for the board:
# echo enabled > /sys/class/tty/ttymxc0/power/wakeup
-
Enter the command below to enter Suspend-To-RAM mode:
# echo mem > /sys/power/statePM: Syncing filesystems ... done.Freezing user space processes ... (elapsed 0.005 seconds) done.Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.Suspending console(s) (use no_console_suspend to debug) -
Press any key on the keyboard to wake up the board. The following messages should appear on
terminal:
PM: suspend of devices complete after 637.926 msecsPM: suspend devices took 0.640 secondsPM: late suspend of devices complete after 1.966 msecsPM: noirq suspend of devices complete after 1.864 msecsDisabling non-boot CPUs ...PM: noirq resume of devices complete after 1.104 msecsPM: resume of devices complete after 99.689 msecsPM: resume devices took 0.110 secondsRestarting tasks ... done.
Demo not working?
Did your board come in a box that looks like this?
No problem! Your board simply came in the old packaging and has a different out-of-box demo loaded into the flash memory.
You should be seeing the red and green LEDs toggling back and forth. It's OK to move onto the next step when you're ready
Still not working?
Try proceeding to the next steps to get other example applications running on your board. If you still have problems, try contacting us through the NXP Community.
Running a demo using Keil® MDK/µVision® Download PDF
1. Install CMSIS device pack
After the MDK tools are installed, Cortex® Microcontroller Software Interface Standard (CMSIS) device packs must be installed to fully support the device from a debug perspective. These packs include things such as memory map information, register definitions and flash programming algorithms. Follow these steps to install the appropriate CMSIS pack.
-
Open the MDK IDE, which is called µVision. In the IDE, select the "Pack Installer" icon.
-
In the Devices tab on the left hand side of the dialog box that appears, expand the NXP category. Then expand the KLxx Series category and highlight KL4x by clicking it once.
-
After the installation finishes, close the Pack Installer window and return to the µVision IDE.
Note:
This process requires an internet connection to successfully complete.
2. Build the Platform Library
These steps show how to open the demo workspace in µVision, how to build the platform library required by the demo, and how to build the demo application.
-
Demo workspace files can be found using this path:
/examples/frdmkl46z/demo_apps/ /mdk The workspace file is named
.uvmpw. For this specific example, the actual path is: /examples/frdmkl46z/demo_apps/hello_world/mdk/hello_world.uvmpw After the workspace is open, two projects show up: one for the KSDK platform library, and one for the demo. By default, the demo project is selected as the active project.
-
Make the platform library project the active project since the library is required by the demo application to build. To make the platform library project active, right click on it and select "Set as Active Project". The active project has a black box around the project name. After it is active, the platform library project is highlighted.
-
There are two project configurations (build targets) supported for each KSDK project:
- Debug — Compiler optimization is set to low, and debug information is generated for the executable. This target should be selected for development and debug.
- Release — Compiler optimization is set to high, and debug information is not generated. This target should be selected for final application deployment.
The tool allows selection of the build target based on the active project, so in order to change the configuration for the platform library it must be the active project. Choose the appropriate build target: "Debug" or "Release" from the drop-down menu.
For this example, select the "ksdk_platform_lib Debug" configuration.
-
Rebuild the project files by left-clicking the "Rebuild" button, highlighted in red.
3. Build a Demo Application
The KSDK demo applications are built upon the software building blocks provided in the Kinetis SDK platform library, built in the previous section. If the platform library is not present, the linker displays an error indicating that it cannot find the library. If the platform library binary is not built and present, follow the steps on page 2 to build it. Otherwise, continue with the following steps to build the desired demo application.
-
If not already done, open the desired demo application workspace in:
/examples/frdmkl46z/demo_apps/ /mdk The workspace file is named
.uvmpw, so for this specific example, the actual path is: /examples/frdmkl46z/demo_apps/hello_world/iar/hello_world.uvmpw -
Make the demo the active project.
-
To build the demo project, select the "Rebuild" button, highlighted in red.
-
The build will complete without errors.
4. Run a Demo Application
The FRDM-KL46Z board comes loaded with the mbed/CMSIS-DAP debug interface from the factory. If you have changed the debug OpenSDA application on your board, visit http://www.nxp.com/opensda for information on updating or restoring your board to the factory state.
-
Connect the development platform to your PC via USB cable between the "SDAUSB" USB port on the board and the PC USB connector.
-
Open the terminal application on the PC (such as PuTTY or TeraTerm) and connect to the debug COM port you determined earlier. Configure the terminal with these settings:
- 115200 baud rate
- No parity
- 8 data bits
- 1 stop bit
-
After the application is properly built, click the "Download" button to download the application to the target.
-
After clicking the "Download" button, the application downloads to the target and should be running. To debug the application, click the "Start/Stop Debug Session" button, highlighted in red.
-
Run the code by clicking the "Run" button to start the application.
-
The hello_world application is now running and a banner is displayed on the terminal. If this is not the case, check your terminal settings and connections.
Running a demo using Kinetis Design Studio IDE Download PDF
1. Install Eclipse Update
Before using KDS IDE with KSDK, the KSDK Eclipse Update must be applied. Without this update, Eclipse cannot generate KSDK-compatible projects.
Windows and Mac® OS Users
The steps required for Mac OS are identical to Windows; the only difference is that the IDE looks slightly different.
-
After installing KDS, check for available updates. Install the Processor Expert 3.0.1 updates from NXP only - do not install any other updates. To check for updates, select “Help” -> “Check for Updates”.
-
Select "Help" -> "Install New Software".
-
In the Install New Software dialog box, click the "Add" button in the upper right corner. Then, in the Add Repository dialog, select the "Archive" button.
-
In the Repository archive dialog box, browse the KSDK install directory
-
Enter the
/tools/eclipse_update folder and select the KSDK__Eclipse_Update.zip file. -
Click "Open", and the "OK" button in the Add Repository dialog box.
-
The KSDK update shows up in the list of the original Install dialogs
-
Check the box to the left of the KSDK Eclipse update and click the "Next" button in the lower right corner.
-
Follow the remaining instructions to finish the installation of the update.
-
After the update is applied, restart KDS for the changes to take effect.
Linux® OS Users
The following instructions were performed using Ubuntu 14.04. These steps may be slightly different for other Linux distributions.
-
Launch KDS IDE from the command line as the root user. On the command line, use this command, assuming the default KDS IDE install path:
user@ubuntu:~$ sudo /opt/NXP/KDS_x.x.x/eclipse/kinetis-design-studioThe KDS IDE version (shown above as x.x.x) should reflect the version installed on your machine, for example, 3.0.0.
-
You are prompted to enter the root password.
-
After installing KDS, check for available updates. Install the Processor Expert 3.0.1 updates from NXP only - do not install any other updates. To check for updates, select “Help” -> “Check for Updates”.
-
Select "Help" -> "Install New Software"
-
In the "Install New Software" dialog box, click the "Add" button in the upper right corner. Then, in the "Add Repository" dialog, select "Archive".
-
In the Repository archive dialog box, browse the KSDK install directory.
-
Enter the
/tools/eclipse_update folder and select the KSDK__Eclipse_Update.zip file. -
Click "Open", and "OK" in the "Add Repository" dialog box.
-
The KSDK update shows up in the list of the original Install dialogs.
-
Check the box to the left of the KSDK Eclipse update and click the "Next" button in the lower right corner.
-
Follow the remaining instructions to finish the installation of the update.
-
After the update is applied, restart the KDS IDE for the changes to take effect.
-
After KDS IDE restarts, shut down the IDE and restart by launching KDS IDE as the non-root user. To do this, follow the command in step 1, only without the "sudo" command.
2. Build the Platform Library
These steps show how to open and build the platform library project in KDS IDE. The platform library is required by the demo and does not build without it.
Note:
The steps required for Linux and Mac OS are identical to those for Windows.
-
Select "File->Import" from the KDS IDE menu. In the window that appears, expand the "General" folder and select "Existing Projects into Workspace". Then, click the "Next" button.
-
Click the "Browse" button next to the "Select root directory:" option.
-
Point to the platform library project for the appropriate device, which can be found using this path:
/lib/ksdk_platform_lib/kds/KL46Z4 -
After pointing to the correct directory, your "Import Projects" window should look like the figure below. Click the "Finish" button.
-
There are two project configurations (build targets) supported for each KSDK project:
- Debug — Compiler optimization is set to low, and debug information is generated for the executable. This target should be selected for development and debug.
- Release — Compiler optimization is set to high, and debug information is not generated. This target should be selected for final application deployment.
-
Choose the appropriate build target, "Debug" or "Release", by clicking the downward facing arrow next to the hammer icon, as shown below. For this example, select the "Debug" target.
-
The library starts building after the build target is selected. To rebuild the library in the future, click the hammer icon (assuming the same build target is chosen).
4. Run a Demo Application
Note:
The steps required for Linux and Mac OS are identical to those for Windows.
The FRDM-KL46Z board comes loaded with the mbed/CMSIS-DAP debug interface from the factory. If you have changed the debug OpenSDA application on your board, visit http://www.nxp.com/opensda for information on updating or restoring your board to the factory state.
Mac users must install the J-Link OpenSDA application in order to use the KDS IDE to download and debug their board.
-
Connect the development platform to your PC via USB cable between the "SDAUSB" USB port on the board and the PC USB connector.
-
Open the terminal application on the PC (such as PuTTY or TeraTerm) and connect to the debug COM port you determined earlier. Configure the terminal with these settings:
- 115200 baud rate
- No parity
- 8 data bits
- 1 stop bit
-
For Linux OS users only, run the following commands in your terminal. These install libudev onto your system, which is required by KDS IDE to launch the debugger.
user@ubuntu:~$ sudo apt-get install libudev-dev libudev1user@ubuntu:~$ sudo ln —s /usr/lib/x86_64-linux-gnu/libudev.so /usr/lib/x86_64-linux-gnu/libudev.so.0 -
Ensure that the debugger configuration is correct for the target you're attempting to connect to. Consult Appendix B for more information about the default debugger application on the various hardware platforms supported by the KSDK.
-
To check the available debugger configurations, click the small downward arrow next to the green "Debug" button and select "Debug Configurations".
-
In the Debug Configurations dialog box, select debug configuration that corresponds to the hardware platform you're using. For Windows or Linux users, select is the CMSIS-DAP/DAPLink option under OpenOCD. For Mac users, select J-Link.
After selecting the debugger interface, click the "Debug" button to launch the debugger.
-
-
The application is downloaded to the target and automatically run to main():
-
Start the application by clicking the "Resume" button:
-
The hello_world application is now running and a banner is displayed on the terminal. If this is not the case, check your terminal settings and connections.
Manufacturing Tool Tutorial - Android™
- Connect a USB cable from a computer running Windows OS to the USB OTG port on the board.
- Unzip the mfgtools.tar.gz file to a selected loation. The directory is named MFGTool-Dir in this example.
- Copy the BSP image to to the path: MFGTool-Dir/Profiles/Linux/OS Firmware/files/android/sabresd
- No dedicated boot DIP switches are reserved for serial download mode on i.MX 6 Quad/QuadPlus SABRE-SD board.One way is to change the SABRE-SD SW6 (boot) to 00001100 (from 1-8 bit) to enter download mode.
- Power on the board.
- Double-click the file *.vbs according to the target device.
- Click "Start" to start downloading. the status bar shows the download status. The download may take one to two minutes depending on the host machine.
- After the image downloading is done, set the boot switch to boot up the board according to the table in the next step.
For details, please refer to "3.3 Downloading Board Images" in i.MX Android™ Quick Start Guide
You can connect a USB cable from the debug UART port to the computer and open a serial communication program for for console output.
Manufacturing Tool Tutorial - Linux®
- Connect a USB cable from a computer to the USB OTG port on the board.
- No dedicated boot DIP switches are reserved for serial download mode on i.MX 6 Quad/QuadPlus
SABRE-SD board.
One way is to set the boot mode to boot from SD slot SD3 but do not insert the SD card, and power on the board. After the message "HID Compliant device" is displayed, the board enters serial download mode. Then insert the SD card into SD slot SD3.See "4.5.11 Serial download mode for the Manufacturing Tool" in i.MX Linux® User Guide. - Power on the board.
- Choose the correct *.vbs file according to the target device. The manufacturing tool automatically pulls the required files based on the device. The default profile of the Manufacturing Tool assumes that your file system is packed and compressed using the bzip2 algorithm. You can also modify the profile to support other formats.
- After the image downloading is done, set the boot switch to boot up the board. See next step in Section 2 in this Getting Started Tutorial or Section "How to boot the i.MX boards" in the document.
For details, please refer to 4.2 Manufacutring Tool in i.MX Linux® User's Guide.
You can connect a USB cable from the debug UART port to the computer and open a serial communication program for for console output.
Boot Switch Setup
The boot modes of the i.MX boards are controlled by the boot configuration boot switches on the board.
The following table shows the boot switch settings (which takes priority in boot process) for booting from the SD card slot labeled SD1/J6 on the i.MX7Dual Sabre board.
Table 1. Booting from SD1/J6 on i.MX7Dual Sabre-SD
| Boot Media | SW2 [D1-D8] |
SW3 [D1-D2] |
|---|---|---|
SD card (SD1) |
00100000 | 10 |
| eMMC | 01010000 | 10 |
| NAND | 011XXXX0 | 10 |
| QuadSPI | 10000000 | 10 |
| SDP | XXXXXXXX | 01 |