MCUXpresso

From Variscite Wiki
DART-MX8M - MCUXpresso 2.5.1

1 Overview

1.1 MCUXpresso SDK

MCUXpresso SDK board support provides example applications for NXP development and evaluation boards for Arm Cortex-M cores. Board support packages are found inside of the top level boards folder, and each supported board has its own folder (MCUXpresso SDK package can support multiple boards). Within each <board_name> folder there are various sub-folders to classify the type of examples they contain. These include (but are not limited to):

  • cmsis_driver_examples: Simple applications intended to concisely illustrate how to use CMSIS drivers.
  • demo_apps: Full-featured applications intended to highlight key functionality and use cases of the target MCU. These applications typically use multiple MCU peripherals and may leverage stacks and middleware.
  • driver_examples: Simple applications intended to concisely illustrate how to use the MCUXpresso SDK’s peripheral drivers for a single use case.
  • rtos_examples: Basic FreeRTOS OS examples showcasing the use of various RTOS objects (semaphores, queues, and so on) and interfacing with the MCUXpresso SDK’s RTOS drivers
  • multicore_examples: Simple applications intended to concisely illustrate how to use middleware/multicore stack

MCUXpresso.png

Here we describe how to use ARM GCC toolchain, officially supported following Getting Started with MCUXpresso SDK i.MX 8M Devices.pdf.


2 Prerequisites

Before starting, prepare a Yocto boot SD (with kernel 4.14.98 or newer).

To allow Cortex M4 accessing shared resources without experiencing Linux kernel conflicts, a dedicated device tree must be loaded, by selecting the right version with the symbolic link in the /boot folder of the booting media.
These device trees contain m4 label in their name.


The below table lists an example dtb blob file name for DART-MX8M (on DT8MCustomBoard rev. 1.3 and higher) with support for M4 (and SD card and LVDS), for each kernel version / Yocto release:

File Name
Description
imx8mq-var-dart-dt8mcustomboard-m4-sd-lvds.dtb For kernel >= 5.4.85 (Yocto >= Dunfell)
imx8mq-var-dart-m4-sd-lvds.dtb For kernel = 5.4.24 (Yocto Zeus)
fsl-imx8mq-var-dart-m4-sd-lvds.dtb For kernel = 4.19.35 (Yocto Warrior)
Image.gz-fsl-imx8mq-var-dart-m4-sd-lvds.dtb For kernel = 4.14.98 (Yocto Sumo)

For the full list of device tree blob files, refer to the "Build Results" section in the appropriate wiki page for the specific Yocto/Debian release you are using.

3 Installing required packages

Install cmake

$ sudo apt-get install cmake

Download and install GNU-ARM bare-metal toolchain:

$ mkdir ~/var-mcuxpresso
$ cd ~/var-mcuxpresso
$ wget https://developer.arm.com/-/media/Files/downloads/gnu-rm/7-2018q2/gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2
$ tar xvf gcc-arm-none-eabi-7-2018-q2-update-linux.tar.bz2

Download MCUXpresso SDK for the SOM:

$ cd ~/var-mcuxpresso
$ git clone https://github.com/varigit/freertos-variscite -b mcuxpresso_sdk_2.5.x-var01
$ cd freertos-variscite

4 Documentation

Original NXP documentation is available online or in the following folder:

~/var-mcuxpresso/freertos-variscite/docs

5 Available demos

All of the Variscite examples are located under the following folder

~/var-mcuxpresso/freertos-variscite/boards/dart_mx8mq

Default M4 pins used by the demos are:

function pin
debug UART (UART2) RX: J12.6 / TX: J12.4
GPIO (GPIO4_IO03) LED7
I2C (I2C3) SCL: J12.18 / SDA: J12.20
PWM (PWM2) J14.3

The available demos for DART-MX8M are:

  • driver_examples/i2c/interrupt_b2b_transfer/slave
  • driver_examples/i2c/interrupt_b2b_transfer/master
  • driver_examples/i2c/polling_b2b_transfer/slave
  • driver_examples/i2c/polling_b2b_transfer/master
  • driver_examples/wdog
  • driver_examples/gpio/led_output
  • driver_examples/tmu/tmu_monitor_report
  • driver_examples/pwm
  • driver_examples/uart/auto_baudrate_detect
  • driver_examples/uart/interrupt
  • driver_examples/uart/interrupt_rb_transfer
  • driver_examples/uart/polling
  • driver_examples/uart/interrupt_transfer
  • driver_examples/gpt/timer
  • driver_examples/gpt/capture
  • driver_examples/ecspi/ecspi_loopback
  • driver_examples/qspi/polling_transfer
  • driver_examples/rdc
  • driver_examples/sema4/uboot
  • rtos_examples/freertos_ecspi/ecspi_loopback
  • rtos_examples/freertos_hello
  • rtos_examples/freertos_queue
  • rtos_examples/freertos_sem
  • rtos_examples/freertos_generic
  • rtos_examples/freertos_uart
  • rtos_examples/freertos_tickless
  • rtos_examples/freertos_mutex
  • rtos_examples/freertos_event
  • rtos_examples/freertos_swtimer
  • rtos_examples/freertos_i2c
  • cmsis_driver_examples/i2c/int_b2b_transfer/slave
  • cmsis_driver_examples/i2c/int_b2b_transfer/master
  • cmsis_driver_examples/uart/interrupt_transfer
  • cmsis_driver_examples/ecspi/int_loopback_transfer
  • multicore_examples/rpmsg_lite_str_echo_rtos
  • multicore_examples/rpmsg_lite_pingpong_rtos/linux_remote
  • demo_apps/hello_world

Almost all of the above demos are also available for EVK-MIMX8MQ.

You can build and run the demos following official NXP documentation for EVK-MIMX8MQ, available online or in the following document:

~/var-mcuxpresso/freertos-variscite/docs/Getting Started with MCUXpresso SDK i.MX 8M Devices.pdf

6 Building a demo

6.1 Building Manually

For any demo, follow these steps:

$ cd ~/var-mcuxpresso/freertos-variscite/boards/dart_mx8mq
$ cd <demo_folder>
$ cd armgcc
$ export ARMGCC_DIR=~/var-mcuxpresso/gcc-arm-none-eabi-7-2018-q2-update
$ ./build_all.sh > /dev/null

You can choose any <demo_folder> from the list available in the previous section.

Then copy the ".bin" to the boot media (either the SD card or eMMC) in the /boot folder already hosting the Linux device trees.

6.2 Building Using Yocto

In Yocto Dunfell and newer, Variscite provides a Yocto recipe for building and installing firmware into the Yocto image:

https://github.com/varigit/meta-variscite-fslc/tree/dunfell/recipes-bsp/freertos-variscite

This recipe installs the following firmware files:

File Memory Loaded Using...
/boot/cm_<demo name>.bin.debug TCM U-Boot
/boot/cm_<demo name>.bin.ddr_debug DDR U-Boot
/lib/firmware/cm_<demo name>.elf.debug TCM Linux Remoteproc Framework
/lib/firmware/cm_<demo name>.elf.ddr_debug DDR Linux Remoteproc Framework

If you have modified freertos-variscite in your own Git repository and kept the same directory structure, you can easily build your custom firmware by creating a bbappend file:

$ mkdir -p <your-layer>/recipes-bsp/freertos-variscite
$ nano <your-layer>/recipes-bsp/freertos-variscite/freertos-variscite_2.9.x.bbappend

Append SRC_URI and SRCREV to use your freertos-variscite Git repository

SRC_URI_remove = "git://github.com/varigit/freertos-variscite.git;protocol=git;branch=${MCUXPRESSO_BRANCH};"
SRC_URI_append = " <your Git repository>"
SRCREV = "<your Git commit id>"

Append CM_DEMOS to build your firmware. For example, to build rtos_examples/freertos_hello:

CM_DEMOS_append = "rtos_examples/freertos_hello"

Rebuild fsl-image-gui:

$ bitbake -c cleansstate freertos-variscite && bitbake fsl-image-gui

The firmware binary files should now be installed to /boot/ and elf files to /lib/firmware/

7 Memory types

The SDK allow linking using 2 different memory types: DDR, TCM.

Here is available a short summary of memory areas used by Cortex-M4 as described in related linker file.

memory type M4 memory area A53 memory area memory lentgh linker file
DDR 0x7E000000-0x7E1FFFFF (code)
0x7E200000-0x7E3FFFFF (data)
0x7E400000-0x7EFFFFFF (data2)
0x7E000000-0x7E1FFFFF (code)
0x7E200000-0x7E3FFFFF (data)
0x7E400000-0x7EFFFFFF (data2)
16MB (DDR) MIMX8MQ6xxxJZ_cm4_ddr_ram.ld
TCM 0x1FFE0000-0x1FFFFFFF (code)
0x20000000-0x2001FFFF (data)
0x7E000000-0x7EFFFFFF (data2)
0x007E0000-0x007FFFFF (code)
0x00800000-0x0081FFFF (data)
0x7E000000-0x7EFFFFFF (data2)
256kB (TCM) + 16MB (DDR) MIMX8MQ6xxxJZ_cm4_ram.ld

All linker files are locate in the armgcc folder of each demo.

The DDR reserved area must much the one declared in the kernel device tree: at least 1 GB of RAM is required on the SoM to allow Cortex-M4 accessing the range 0x7E000000 - 0x7EFFFFFF. For some reason, Cortex-M4 is not able to access RAM locations below 0x60000000: SoMs with 512 MB of RAM are not suitable to use Cortex-M4.

The RPMSG area is located at 0x40000000: all SoMs allow Cortex-M4 accessing the RPMSG area.

After launching the build_all.sh command the following folder will be created in the armgcc folder

  • ddr_debug: containing DDR binaries compiled in debug mode (not stripped: symbols available)
  • ddr_release: containing DDR binaries compiled in release mode (stripped: no symbols available)
  • debug: containing TCM binaries compiled in debug mode (not stripped: symbols available)
  • release: containing TCM binaries compiled in release mode (stripped: no symbols available)

Further details about memory mapping are available in i.MX 8M Applications Processors Reference Manual paragraphs:

  • 2.1.2 Cortex-A53 Memory Map
  • 2.1.3 Cortex-M4 Memory Map

8 Running a demo

8.1 Running a demo from U-Boot

To allow Cortex-M accessing shared resources without experiencing Linux kernel conflicts, a dedicated device tree must be loaded.

To enable Cortex-M:

=> setenv use_m4 yes; saveenv

To disable Cortex-M:

=> setenv use_m4 no; saveenv

Binary demos must be loaded to the memory type used for linking.

To use TCM:

=> setenv m4_addr 0x7E0000; saveenv

To use DDR:

=> setenv m4_addr 0x7E000000; saveenv

To set the name of the Cortex-M binary

=> setenv m4_bin myapp.bin; saveenv

The .bin file is expected in the folder /boot of the booting media.

The U-Boot boot command will take care to correctly load the Cortex-M firmware and start Linux for DART-MX8M

For testing, it is possible to run the firmware manually

=> run loadm4bin && run runm4bin

Additional details and step by step procedure to run each of the demos is available online or in the following document:

~/var-mcuxpresso/freertos-variscite/docs/Getting Started with MCUXpresso SDK i.MX 8M Devices.pdf


For Yocto Dunfell and newer, this process can be simplified using /etc/remoteproc/variscite-rproc-u-boot
Please refer to the Yocto Scripts section below for more information

8.2 Running a demo from Linux

Note: The Linux remoteproc framework is currently supported by the following configurations:

Variscite SOM Kernel Version
imx8mm-var-som 5.4-2.1.x-imx_var01 or newer
imx8mm-var-dart 5.4-2.1.x-imx_var01 or newer
imx8mn-var-som 5.4-2.1.x-imx_var01 or newer
imx8mq-var-dart 5.4-2.1.x-imx_var01 or newer
imx8qm-var-som 5.4-2.1.x-imx_var01 or newer
imx8qm-var-spear 5.4-2.1.x-imx_var01 or newer
imx8qxp-var-som 5.4-2.1.x-imx_var01 or newer
imx8mp-var-som imx_5.4.70_2.3.2_var01 only
imx8mp-var-dart imx_5.4.70_2.3.2_var01 only

Boot Linux after follow steps in #Running a demo from U-Boot

Increase kernel loglevel while debugging:

# sysctl kernel.printk=7;

Check the state of the m4, it should be running already by U-Boot

# cat /sys/class/remoteproc/remoteproc0/state

If the state is 'running', stop the m4

# echo stop > /sys/class/remoteproc/remoteproc0/state

Load new firmware (.elf file must already exist in /lib/firmware directory)

# echo hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware

Run the new firmware

# echo start > /sys/class/remoteproc/remoteproc0/state



For Yocto Dunfell and newer, this process can be simplified using /etc/remoteproc/variscite-rproc-linux
Please refer to the Yocto Scripts section below for more information


8.3 Running a Demo using Yocto Scripts

In Yocto Dunfell and newer, Variscite provides scripts to simplify loading firmware via U-Boot or Linux:

Script Description
/etc/remoteproc/variscite-rproc-u-boot Configure U-Boot to load firmware on boot
/etc/remoteproc/variscite-rproc-linux Load and run firmware using Linux remoteproc framework

Examples

variscite-rproc-u-boot example on imx8mm-var-dart:

root@imx8mm-var-dart:~# /etc/remoteproc/variscite-rproc-u-boot -f /boot/cm_hello_world.bin.ddr_debug
Configuring for DDR memory
+ fw_setenv m4_addr 0x7E000000
+ fw_setenv fdt_file imx8mm-var-som-symphony-m4.dtb
+ fw_setenv use_m4 yes
+ fw_setenv m4_bin cm_hello_world.bin.ddr_debug

Finished: Please reboot, the m4 firmware will run during U-Boot

variscite-rproc-linux example on imx8mm-var-dart:

root@imx8mm-var-dart:~# /etc/remoteproc/variscite-rproc-linux -f /lib/firmware/cm_hello_world.elf.ddr_debug
Cortex-M: Stopping
[  359.212638] remoteproc remoteproc0: stopped remote processor imx-rproc
[  359.219709] remoteproc remoteproc0: powering up imx-rproc
Cortex-M: Loading cm_hello_world.elf.ddr_debug
[  359.227101] remoteproc remoteproc0: Booting fw image cm_hello_world.elf.ddr_debug, size 269100
[  359.238493] imx-rproc imx8mm-cm4: m4 ddr @ 0x7e000000
[  359.243584] remoteproc remoteproc0: no dtb rsrc-table
[  359.248797] imx-rproc imx8mm-cm4: Setting up stack pointer and reset vector from firmware in DDR
[  359.257626] imx-rproc imx8mm-cm4: Stack: 0x7e400000
[  359.262542] imx-rproc imx8mm-cm4: Reset Vector: 0x7e00030d
Cortex-M: Starting
[  359.318074] remoteproc remoteproc0: remote processor imx-rproc is now up


9 Debugging a demo

9.1 JTAG interface

Cortex-M debugging may require JTAG.

The VAR-DT8MCustomBoard exports the DART-MX8M JTAG signals through J29, a standard 1.27" 10 pin header.

Here the pinout

pin signal description pin signal description
1 JTAG_VREF JTAG IO reference voltage,
connects to SOM_NVCC_3V3.
2 JTAG_TMS JTAG Mode Select signal
3 GND Digital Ground 4 JTAG_TCK JTAG Clock signal,
requires 10K pull down.
5 GND Digital Ground 6 JTAG_TDO JTAG Data Out signal
7 GND Digital Ground 8 JTAG_TDI JTAG Data In signal
9 JTAG_NTRST_C JTAG Reset signal 10 NRST_CON Programmer Reset,
used to put the SOC in reset state.

Please refer to board schematics for further details.

9.2 Debugging GUI

A detailed step by step procedure to debug using SEGGER J-Link is available online or in the following document:

~/var-mcuxpresso/freertos-variscite/docs/Getting Started with MCUXpresso SDK i.MX 8M Devices.pdf