MCUXpresso: Difference between revisions
(25 intermediate revisions by 2 users not shown) | |||
Line 18: | Line 18: | ||
Here we describe how to use ARM GCC toolchain, officially supported following [{{#var:SDK_GIT_URL}}/blob/{{#var:SDK_GIT_BRANCH}}/{{#var:DOCS_FOLDER}}/{{urlencode:{{#var:NXP_USER_GUIDE}}|PATH}} {{#var:NXP_USER_GUIDE}}]. | Here we describe how to use ARM GCC toolchain, officially supported following [{{#var:SDK_GIT_URL}}/blob/{{#var:SDK_GIT_BRANCH}}/{{#var:DOCS_FOLDER}}/{{urlencode:{{#var:NXP_USER_GUIDE}}|PATH}} {{#var:NXP_USER_GUIDE}}]. | ||
{{#if: {{#var:SOC_HAS_SCU}} | | |||
== iMX8 QM/QX boot flow == | |||
The boot process for iMX8WM/QX SoCc begins at Power On Reset (POR) where the hardware reset logic forces the | |||
System Controller (SCU) to begin execution starting from its on-chip boot ROM. | |||
The platform boot is performed by the SCU and the Security Controller (SECO), working in concert to ensure that the intended and authorized set of images are loaded and started on various processing domains contained by the SoC. | |||
The SCU plays the role of platform manager: it's the core that will interpret the boot settings, configure the interfaces/boot sources, look for the containers with boot images, and load these to the target on-chip or external memories. | |||
Both the SCU and the SECO start execution, upon SoC POR, in their respective ROM memories. | |||
A firmware (FW) image will be loaded for each as part of the boot process. | |||
The images that will be loaded as part of the boot process are stored in containers. | |||
A container can contain one or multiple images, as blocks of data specifying the load address, target address, etc. | |||
At least two containers are needed for the boot process: | |||
* The first container will only contain the SECO FW Image. | |||
* The second container will typically contain: | |||
** The SCU FW image (SCFW) | |||
** The DDR Initialization image (embedded in SCFW) | |||
** The Cortex-M4 FW image(s) | |||
** The FW image(s) for the Cortex-A processing domain | |||
[[File:imx8-boot-flow.png]] | |||
In this scenario, the SCU plays the critical role to assign the resources before loading the Cortex-M4 and Cortex-A images. | |||
Once the SCFW assigns specific resource to the Cortex-M4, this resource is not even visible from the Cortex-A, avoiding the need of dedicated device trees to prevent resource contentions. | |||
}} | |||
=Prerequisites= | =Prerequisites= | ||
{{#if: {{#var:SOC_HAS_SCU}} | | |||
As explained above, the SCU is in charge to assign resources before loading the images. | |||
This means that the SCFW must be customized and rebuilt in order to assign required resources and pins to the M4. | |||
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 | |||
cd imx-scfw-porting-kit/src | |||
wget {{#var:SCFW_PATCH_URL}}/{{#var:SCFW_M4_PATCH}} | |||
cd scfw_export_{{#var:SCFW_SOC}} | |||
patch -p1 < ../{{#var:SCFW_M4_PATCH}} | |||
}} | |||
| | |||
Before starting, prepare a [[{{#var:HARDWARE_NAME}} | Yocto]] boot SD (Sumo or newer). | Before starting, prepare a [[{{#var:HARDWARE_NAME}} | Yocto]] boot SD (Sumo or newer). | ||
{{#lst:MCUXpresso_Platform_Customization|{{#var:DTBS_SECTION}}}} | {{#lst:MCUXpresso_Platform_Customization|{{#var:DTBS_SECTION}}}} | ||
}} | |||
=Installing required packages= | =Installing required packages= | ||
Line 79: | Line 145: | ||
You can choose any <demo_folder> from the list available in the previous section. | You can choose any <demo_folder> from the list available in the previous section. | ||
{{#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. | |||
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_image.bin'''> m4_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 images generated in the release folder | |||
* '''flash_regression_linux_m4_ddr''': for images generated in the ddr_release folder | |||
}} | |||
| | |||
Then copy the ".bin" to the boot media (either the SD or eMMC) in the /boot folder already hosting the Linux device trees. | 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= | =Memory types= | ||
Line 87: | Line 199: | ||
=Running a demo= | =Running a demo= | ||
{{#if: {{#var:SOC_HAS_SCU}} | | |||
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 | To allow Cortex-M accessing shared resources without experiencing Linux kernel conflicts, a dedicated device tree must be loaded. | ||
To enable Cortex | To enable Cortex-M: | ||
setenv | setenv use_{{#var:CORTEX_M_TYPE}} yes; saveenv | ||
To disable Cortex | To disable Cortex-M: | ||
setenv | 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 106: | Line 226: | ||
To use TCM: | To use TCM: | ||
setenv | setenv {{#var:CORTEX_M_TYPE}}_addr 0x7e0000; saveenv | ||
To use DDR: | To use DDR: | ||
setenv | setenv {{#var:CORTEX_M_TYPE}}_addr 0x7E000000; saveenv | ||
To set the name of the Cortex-M binary | |||
setenv {{#var:CORTEX_M_TYPE}}_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 {{#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: | |||
{{#var:SDK_PATH}}/freertos-variscite/{{#var:DOCS_FOLDER}}/{{#var:NXP_USER_GUIDE}} | |||
}} | |||
=Debugging a demo= | =Debugging a demo= | ||
Line 122: | Line 250: | ||
== JTAG interface== | == JTAG interface== | ||
Cortex | 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
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
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