MCUXpresso: Difference between revisions

From Variscite Wiki
(4 intermediate revisions by 2 users not shown)
Line 63: Line 63:


You can build it by following the {{Varlink|Yocto_Build_SCFW|{{#var:YOCTO_RELEASE_LINK}}|Build SCFW from source code}} page, but remember the default build will not enable M4 resources.
You can build it by following the {{Varlink|Yocto_Build_SCFW|{{#var:YOCTO_RELEASE_LINK}}|Build SCFW from source code}} page, but remember the default build will not enable M4 resources.
{{#if: {{#var:SCFW_DEFINES_URL}} |
For your convenience, you can enable some sample defines here,
{{#var:SCFW_DEFINES_URL}}
allowing some sample resource assignments referenced in the BSP.
|


Before starting the building stage describe in paragraph 3 of the above link, we propose the following additional patch
Before starting the building stage describe in paragraph 3 of the above link, we propose the following additional patch
Line 70: Line 80:
  cd scfw_export_{{#var:SCFW_SOC}}
  cd scfw_export_{{#var:SCFW_SOC}}
  patch -p1 < ../{{#var:SCFW_M4_PATCH}}
  patch -p1 < ../{{#var:SCFW_M4_PATCH}}
}}


|
|
Line 135: Line 147:


{{#if: {{#var:SOC_HAS_SCU}} |
{{#if: {{#var:SOC_HAS_SCU}} |
{{#if: {{#var:SOC_HAS_M40_M41}} |
The (optional M4_0 and) M4_1 images need now to be integrated in the uboot.
You can build uboot by following the {{Varlink|Yocto_Build_U-Boot|{{#var:YOCTO_RELEASE_LINK}}|Build U-Boot from source code}} page, but remember that you need to use a different build target and link the M4 image.
To build boot image, replace the commands available in the above page (at the end of secion 3), with
ln -sf <'''full_path_to_M4_0_image.bin'''> m4_image.bin
ln -sf <'''full_path_to_M4_1_image.bin'''> m4_1_image.bin
make -f soc.mak clean
make -f soc.mak SOC={{#var:IMX_MKIMAGE_SOC}} MKIMG=./mkimage_imx8 PAD_IMAGE=./pad_image.sh <'''flash_target'''>
mv flash.bin imx-boot-sd.bin
There are two possible flash_targets: the flash_target must match the linker options used to generate the binary (refer to the next section for further detains):
* '''flash_regression_linux_m4''': for M4 0 and M4 1 images generated in the release folder
* '''flash_regression_linux_m4_ddr''': for M4 0 and M4 1 images generated in the ddr_release folder
* '''flash_regression_linux_m41''': for M4 1 (only) images generated in the release folder
* '''flash_regression_linux_m41_ddr''': for M4 1 (only) images generated in the ddr_release folder
|


The M4 image need now to be integrated in the uboot.
The M4 image need now to be integrated in the uboot.
Line 151: Line 186:
* '''flash_regression_linux_m4''': for images generated in the release folder  
* '''flash_regression_linux_m4''': for images generated in the release folder  
* '''flash_regression_linux_m4_ddr''': for images generated in the ddr_release folder  
* '''flash_regression_linux_m4_ddr''': for images generated in the ddr_release folder  
}}


|
|
Line 165: Line 201:
{{#if: {{#var:SOC_HAS_SCU}} |
{{#if: {{#var:SOC_HAS_SCU}} |


Since the SCU will automatically read and load the M4 application, no actions are required by the users.
Since the SCU will automatically read and load the Cortex-M application, no actions are required by the users.


|
|
<!-- Set local variables
--> {{#vardefine:CORTEX_M_TYPE | <!--
-->    {{#switch:{{#var:HARDWARE_NAME}} | <!--
-->      VAR-SOM-MX8M-NANO = m7 | <!--
-->      m4 <!--
-->    }} <!--
--> }}


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


To enable Cortex M4:
To enable Cortex-M:


  setenv use_m4 yes; saveenv
  setenv use_{{#var:CORTEX_M_TYPE}} yes; saveenv


To disable Cortex M4:
To disable Cortex-M:


  setenv use_m4 no; saveenv
  setenv use_{{#var:CORTEX_M_TYPE}} no; saveenv


Binary demos must be loaded to the memory type used for linking.
Binary demos must be loaded to the memory type used for linking.
Line 183: Line 226:
To use TCM:
To use TCM:


  setenv m4_addr 0x7e0000; saveenv
  setenv {{#var:CORTEX_M_TYPE}}_addr 0x7e0000; saveenv


To use DDR:
To use DDR:


  setenv m4_addr 0x7E000000; saveenv
  setenv {{#var:CORTEX_M_TYPE}}_addr 0x7E000000; saveenv


To set the name of the M4 binary
To set the name of the Cortex-M binary


  setenv m4_bin myapp.bin; saveenv
  setenv {{#var:CORTEX_M_TYPE}}_bin myapp.bin; saveenv


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


The uboot '''boot''' command will take care to correctly load the M4 firmware and start Linux for {{#var:HARDWARE_NAME}}
The uboot '''boot''' command will take care to correctly load the Cortex-M firmware and start Linux for {{#var:HARDWARE_NAME}}


Additional details and step by step procedure to run each of the demos is available [{{#var:SDK_GIT_URL}}/blob/{{#var:SDK_GIT_BRANCH}}/{{#var:DOCS_FOLDER}}/{{urlencode:{{#var:NXP_USER_GUIDE}}|PATH}} online] or in the following document:
Additional details and step by step procedure to run each of the demos is available [{{#var:SDK_GIT_URL}}/blob/{{#var:SDK_GIT_BRANCH}}/{{#var:DOCS_FOLDER}}/{{urlencode:{{#var:NXP_USER_GUIDE}}|PATH}} online] or in the following document:
Line 207: Line 250:
== JTAG interface==
== JTAG interface==


Cortex M4 debugging requires JTAG.
Cortex-M debugging may require JTAG.


{{#lst:MCUXpresso_Platform_Customization|{{#var:JTAG_SECTION}}}}
{{#lst:MCUXpresso_Platform_Customization|{{#var:JTAG_SECTION}}}}

Revision as of 17:36, 3 May 2020

DART-MX8M - MCUXpresso 2.5.1

Overview

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.


Prerequisites

Before starting, prepare a Yocto boot SD (Sumo 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.

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

Documentation

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

~/var-mcuxpresso/freertos-variscite/docs

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 for DT8CustomBoard 1.x
U43.2 / R228 for DT8CustomBoard >= 2.0 (Use Oscilloscope to observe output signal)
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

Building a demo

For any demo just follow this 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 or eMMC) in the /boot folder already hosting the Linux device trees.

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 0x80000000-0x801FFFFF (code)
0x80200000-0x803FFFFF (data)
0x80400000-0x80FFFFFF (data2)
0x80000000-0x801FFFFF (code)
0x80200000-0x803FFFFF (data)
0x80400000-0x80FFFFFF (data2)
16MB (DDR) MIMX8MQ6xxxJZ_cm4_ddr_ram.ld
TCM 0x1FFE0000-0x1FFFFFFF (code)
0x20000000-0x2001FFFF (data)
0x80000000-0x80FFFFFF (data2)
0x007E0000-0x007FFFFF (code)
0x00800000-0x0081FFFF (data)
0x80000000-0x80FFFFFF (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 match the one declared in the kernel device tree: at least 2 GB of RAM is required on the SoM to allow Cortex-M4 accessing the range 0x80000000 - 0x80FFFFFF.

The RPMSG area is located at 0xB8000000: at least 3 GB of RAM is required on the SoM to 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 the following i.MX 8M Applications Processor Reference Manual paragraphs:

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

Running a demo

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 uboot boot command will take care to correctly load the Cortex-M firmware and start Linux for DART-MX8M

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

Debugging a demo

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 is 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.

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