MCUXpresso: Difference between revisions

From Variscite Wiki
(Make AN5317 note only show to i.MX 8M Plus MCUXpresso pages)
 
(211 intermediate revisions by 8 users not shown)
Line 1: Line 1:
<!-- Set release according to "release" parameter in URL and use MCUXPRESSO_2.5.1_V1.0_DART-MX8M as default
<!-- Set release according to "release" parameter in URL and use MCUXPRESSO_2.5.1_V1.0_DART-MX8M as default
--> {{#vardefine:RELEASE_PARAM|{{#urlget:release}}}} <!--
--> {{#vardefine:RELEASE_PARAM|{{#urlget:release}}}} <!--
--> {{#lst:MCUXpresso_Platform_Customization|{{#var:RELEASE_PARAM|MCUXPRESSO_2.5.1_V1.0_DART-MX8M}}}} <!--
--> {{#vardefine:RELEASE_PARAM|{{#var:RELEASE_PARAM|MCUXPRESSO_2.5.1_V1.0_DART-MX8M}}}} <!--
--> {{#lst:MCUXpresso_Platform_Customization|{{#var:RELEASE_PARAM}}}} <!--
--> {{#lst:MCUXpresso_Platform_Customization|MCUXPRESSO_GLOBALS}} <!--
--> {{PageHeader|{{#var:HARDWARE_NAME}} - MCUXpresso {{#var:MCUXPRESSO_VERSION}}}} {{DocImage|category1={{#var:HARDWARE_NAME}}|category2=MCUXpresso}} __toc__
--> {{PageHeader|{{#var:HARDWARE_NAME}} - MCUXpresso {{#var:MCUXPRESSO_VERSION}}}} {{DocImage|category1={{#var:HARDWARE_NAME}}|category2=MCUXpresso}} __toc__


Line 7: Line 9:


==MCUXpresso SDK==
==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):
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 may include (but are not limited to):


* cmsis_driver_examples: Simple applications intended to concisely illustrate how to use CMSIS drivers.
* 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.
* 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.
* 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
* 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
* multicore_examples: Simple applications intended to concisely illustrate how to use middleware/multicore stack.


[[File:MCUXpresso.png]]
[[File:MCUXpresso.png]]


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 iMX8QM/QX SoCs 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=


Before starting, prepare a [[{{#var:HARDWARE_NAME}} | Yocto]] boot SD (Sumo or newer).
{{#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}}
 
}}
 
|
 
{{#switch: {{#var:HARDWARE_NAME}}
| VAR-SOM-MX8X = {{#vardefine:MINIMAL_KERNEL_VERSION|5.4.85}}
| VAR-SOM-MX8 = {{#vardefine:MINIMAL_KERNEL_VERSION|5.4.85}}
| VAR-SOM-MX93 = {{#vardefine:MINIMAL_KERNEL_VERSION|6.1.1}}
| {{#vardefine:MINIMAL_KERNEL_VERSION|4.14.98}}
}}
 
Before starting, prepare a [[{{#var:HARDWARE_NAME}} | Yocto]] boot SD card (with kernel {{#var:MINIMAL_KERNEL_VERSION}} or newer).
 
{{#lst:MCUXpresso_Platform_Customization|{{#var:DTBS_SECTION}}}}
 
}}


=Installing required packages=
=Installing required packages=
Install cmake
$ sudo apt-get install cmake


Download and install GNU-ARM bare-metal toolchain:
Download and install GNU-ARM bare-metal toolchain:


  mkdir {{#var:SDK_PATH}}
  $ mkdir {{#var:SDK_PATH}}
  cd {{#var:SDK_PATH}}
  $ cd {{#var:SDK_PATH}}
  wget {{#var:TOOLCHAIN_URL}}
  $ wget {{#var:TOOLCHAIN_URL}}
  tar xvf {{#var:TOOLCHAIN_BZ2_NAME}}
  $ tar xvf {{#var:TOOLCHAIN_BZ2_NAME}}


Download MCUXpresso SDK for the SOM:
Download MCUXpresso SDK for the SOM:


  cd {{#var:SDK_PATH}}
  $ cd {{#var:SDK_PATH}}
  git clone {{#var:SDK_GIT_URL}} -b {{#var:SDK_GIT_BRANCH}}
  $ git clone {{#var:SDK_GIT_URL}} -b {{#var:SDK_GIT_BRANCH}}
  cd freertos-variscite
  $ cd freertos-variscite


=Documentation=
=Documentation=
Line 43: Line 124:


  {{#var:SDK_PATH}}/freertos-variscite/{{#var:DOCS_FOLDER}}
  {{#var:SDK_PATH}}/freertos-variscite/{{#var:DOCS_FOLDER}}
=Demos pins=
{{#lst:MCUXpresso_Platform_Customization|{{#var:PINS_SECTION}}}}


=Available demos=
=Available demos=
Line 49: Line 133:


  {{#var:SDK_PATH}}/freertos-variscite/{{#var:BOARD_FOLDER}}
  {{#var:SDK_PATH}}/freertos-variscite/{{#var:BOARD_FOLDER}}
{{#if: {{#var:BOARD_FOLDER1}} |
{{#var:SDK_PATH}}/freertos-variscite/{{#var:BOARD_FOLDER1}}
}}
The available demos for {{#var:HARDWARE_NAME}} {{#if: {{#var:HARDWARE_NAME1}} | and {{#var:HARDWARE_NAME1}} }} are:
{{#lst:MCUXpresso_Platform_Customization|{{#var:DEMOS_SECTION}}}}
Almost all of the above demos are also available for {{#var:NXP_REFERENCE_KIT}}.
You can build and run the demos following official NXP documentation for {{#var:NXP_REFERENCE_KIT}}, 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}}
=Building a demo=
==Building Manually==
For any demo, follow these steps:
$ cd {{#var:SDK_PATH}}/freertos-variscite/{{#var:BOARD_FOLDER}}
$ cd <demo_folder>
$ cd armgcc
$ export ARMGCC_DIR={{#var:SDK_PATH}}/{{#var:TOOLCHAIN_FOLDER}}
$ ./build_all.sh > /dev/null
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 U-Boot.
You can build U-Boot 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):
For BSP version 4.14.98_2.0.0
* '''flash_regression_linux_m4''': for M4 0 and M4 1 images generated in the release folder (M4 code located in TCM)
* '''flash_regression_linux_m4_ddr''': for M4 0 and M4 1 images generated in the ddr_release folder (M4 code located in DDR)
* '''flash_regression_linux_m41''': for M4 1 (only) images generated in the release folder (M4 code located in TCM)
* '''flash_regression_linux_m41_ddr''': for M4 1 (only) images generated in the ddr_release folder (M4 code located in DDR)
Fow new version of BSPs
* '''flash_linux_m4''': for M4 0 and M4 1 images generated in the release folder (M4 code located in TCM)
|
The M4 image need now to be integrated in U-Boot.
You can build U-Boot 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 a 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):
For BSP 4.14.98_2.0.0
* '''flash_regression_linux_m4''': for images generated in the release folder (M4 code located in TCM)
* '''flash_regression_linux_m4_ddr''': for images generated in the ddr_release folder (M4 code located in DDR)
For new version of BSPs
* '''flash_linux_m4''': for images generated in the release folder
}}
|
Then copy the ".bin" to the boot media (either the SD card or eMMC) in the /boot folder already hosting the Linux device trees.
}}
==Building Using Yocto==
{{#ifeq: {{#var:HARDWARE_NAME}} | DART-MX8M-PLUS |
In Yocto Zeus and newer, Variscite provides a Yocto recipe for building and installing firmware into the Yocto image:
https://github.com/varigit/meta-variscite-imx/tree/zeus-imx-5.4.70-2.3.2-var01/recipes-bsp/freertos-variscite
|
In Yocto Dunfell and newer, Variscite provides a Yocto recipe for building and installing firmware into the Yocto image. Note, the examples below apply to the original release of this recipe in Dunfell and thus some of the syntax (such as the overrides) may need to be updated for newer versions.
https://github.com/varigit/meta-variscite-fslc/tree/dunfell/recipes-bsp/freertos-variscite
}}


Default M4 pin settings are used by demo applications:
This recipe installs the following firmware files:


{| class="wikitable"
{| class="wikitable"
|-
|-
! scope="col" | function
! File
! scope="col" | pin
! Memory
|-
! Loaded Using...
| debug UART (UART2)
 
| RX: J12.6 / TX: J12.4
{{#switch: {{#var:HARDWARE_NAME}}
|-
| DART-MX8M-PLUS =
| GPIO (GPIO4_IO03)
 
| LED1
{{!}}-
|-
{{!}} /boot/cm_<demo name>.bin.debug_dart {{!}}{{!}} TCM {{!}}{{!}} U-Boot
| I2C (I2C3)
{{!}}-
| SCL: J12.18 / SDA: J12.20
{{!}} /boot/cm_<demo name>.bin.debug_som {{!}}{{!}} TCM {{!}}{{!}} U-Boot
|-
{{!}}-
| PWM (PWM4)
{{!}} /boot/cm_<demo name>.bin.ddr_debug_dart {{!}}{{!}} DDR {{!}}{{!}} U-Boot
| J14.3
{{!}}-
|-
{{!}} /boot/cm_<demo name>.bin.ddr_debug_som {{!}}{{!}} DDR {{!}}{{!}} U-Boot
|}
{{!}}-
{{!}} /lib/firmware/cm_<demo name>.elf.debug_dart {{!}}{{!}} TCM {{!}}{{!}} Linux Remoteproc Framework
{{!}}-
{{!}} /lib/firmware/cm_<demo name>.elf.debug_som {{!}}{{!}} TCM {{!}}{{!}} Linux Remoteproc Framework
{{!}}-
{{!}} /lib/firmware/cm_<demo name>.elf.ddr_debug_dart {{!}}{{!}} DDR {{!}}{{!}} Linux Remoteproc Framework
{{!}}-
{{!}} /lib/firmware/cm_<demo name>.elf.ddr_debug_som {{!}}{{!}} DDR {{!}}{{!}} Linux Remoteproc Framework
 
| VAR-SOM-MX93 =
 
{{!}}-
{{!}} /boot/cm_<demo name>.bin.debug {{!}}{{!}} TCM {{!}}{{!}} U-Boot
{{!}}-
{{!}} /lib/firmware/cm_<demo name>.elf.debug {{!}}{{!}} TCM {{!}}{{!}} Linux Remoteproc Framework
 
|


The available demos for {{#var:HARDWARE_NAME}} are:
{{!}}-
{{!}} /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


{{#lst:MCUXpresso_Platform_Customization|{{#var:DEMOS_SECTION}}}}
}}
|}
{{#vardefine:YOCTO_RECIPE_NAME|freertos-variscite_2.9.x.bbappend}}
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:


Almost all of the above demos are also available for {{#var:NXP_REFERENCE_KIT}}.
$ mkdir -p <your-layer>/recipes-bsp/freertos-variscite
$ nano <your-layer>/recipes-bsp/freertos-variscite/{{#var:YOCTO_RECIPE_NAME}}


You can build and run the demos following official NXP documentation for {{#var:NXP_REFERENCE_KIT}}, 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:
Append '''SRC_URI''' and '''SRCREV''' to use your freertos-variscite Git repository


  {{#var:SDK_PATH}}/freertos-variscite/{{#var:DOCS_FOLDER}}/{{#var:NXP_USER_GUIDE}}
  # Yocto Hardknott and older
SRC_URI_remove = "git://github.com/varigit/freertos-variscite.git;protocol=git;branch=${MCUXPRESSO_BRANCH};"
SRC_URI_append = " <your Git repository>"
# Yocto Kirkstone and newer
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>"


=Building a demo=
Append '''CM_DEMOS''' to build your firmware. For example, to build rtos_examples/freertos_hello:
# Yocto Hardknott and older
CM_DEMOS_append = "rtos_examples/freertos_hello"
# Yocto Kirkstone and newer
CM_DEMOS:append = "rtos_examples/freertos_hello"


For any demo just follow this steps:
Rebuild fsl-image-gui:


  cd {{#var:SDK_PATH}}/freertos-variscite/{{#var:BOARD_FOLDER}}
  $ bitbake -c cleansstate freertos-variscite && bitbake fsl-image-gui
cd <demo_folder>
cd armgcc
export ARMGCC_DIR={{#var:SDK_PATH}}/{{#var:TOOLCHAIN_FOLDER}}
./build_all.sh > /dev/null


Then copy the ".bin" in the same location hosting the Linux device trees.
The firmware binary files should now be installed to /boot/ and elf files to /lib/firmware/


=Memory types=
=Memory types=
Line 98: Line 311:


=Running a demo=
=Running a demo=
{{#switch: {{#var:HARDWARE_NAME}}
| VAR-SOM-MX93=<!-- -->{{#lst:MCUXpresso_Platform_Customization|VAR-SOM-MX93_RUNNING_DEMO_SECTION}}
| #default=<!--
-->== Running a demo from U-Boot ==
{{#if: {{#var:SOC_HAS_SCU}} |


A detailed step by step procedure to running 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:
Since the SCU will automatically read and load the Cortex-M application, no actions are required by the users.


{{#var:SDK_PATH}}/freertos-variscite/{{#var:DOCS_FOLDER}}/{{#var:NXP_USER_GUIDE}}
|


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
  {{#if: {{#var:SOC_HAS_M40_M41}} |
=> setenv use_m40 yes; saveenv
=> setenv use_m41 yes; saveenv
|
=> setenv use_{{#var:CORTEX_M_TYPE}} yes; saveenv
}}


To disable Cortex M4:
To disable Cortex-M:


  setenv use_m4 no; saveenv
  {{#if: {{#var:SOC_HAS_M40_M41}} |
=> setenv use_m40 no; saveenv
=> setenv use_m41 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 117: Line 345:
To use TCM:
To use TCM:


  setenv m4_addr 0x7e0000; saveenv
  {{#if: {{#var:SOC_HAS_M40_M41}} |
(default setting)
=> setenv m40_addr 0x88000000; saveenv (TCM is at 0x34FE0000, but U-Boot load to 0x88000000)
=> setenv m41_addr 0x88800000; saveenv  (TCM is at 0x38FE0000, but U-Boot load to 0x88800000)
|
{{#ifeq: {{#var:HARDWARE_NAME}} | VAR-SOM-MX8X |
=> setenv {{#var:CORTEX_M_TYPE}}_addr 0x88000000; saveenv  (TCM is at 0x34FE0000, but U-Boot load to 0x88000000)
|
=> setenv {{#var:CORTEX_M_TYPE}}_addr 0x7E0000; saveenv
}}
}}


To use DDR:
To use DDR:


  setenv m4_addr 0x80000000; saveenv
  {{#if: {{#var:SOC_HAS_M40_M41}} |
(default setting)
=> setenv m40_addr 0x88000000; saveenv
=> setenv m41_addr 0x88800000; saveenv
|
{{#ifeq: {{#var:HARDWARE_NAME}} | VAR-SOM-MX8X |
=> setenv {{#var:CORTEX_M_TYPE}}_addr 0x88000000; saveenv
|
{{#ifeq: {{#var:HARDWARE_NAME}} | DART-MX8M-PLUS |
=> setenv {{#var:CORTEX_M_TYPE}}_addr 0x80000000; saveenv
|
=> setenv {{#var:CORTEX_M_TYPE}}_addr 0x7E000000; saveenv
}}
}}
}}
To set the name of the Cortex-M binary


To set the name of the M4 binary
{{#if: {{#var:SOC_HAS_M40_M41}} |
=> setenv m40_bin myapp.bin; saveenv
=> setenv m41_bin myapp.bin; saveenv
|
=> setenv {{#var:CORTEX_M_TYPE}}_bin myapp.bin; saveenv
}}


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 M4 firmware and start Linux for {{#var:HARDWARE_NAME}}
The U-Boot '''boot''' command will handle loading the Cortex-M firmware and start Linux for {{#var:HARDWARE_NAME}}.
 
For testing, it is possible to run the firmware manually:
 
{{#if: {{#var:SOC_HAS_M40_M41}} |
=> run loadm40bin && run runm40bin
=> run loadm41bin && run runm41bin
|
=> run load{{#var:CORTEX_M_TYPE}}bin && run run{{#var:CORTEX_M_TYPE}}bin
}}
 
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}}
 
}}
 
{{note|For Yocto Dunfell and newer, this process can be simplified using /etc/remoteproc/variscite-rproc-u-boot<br>
Please refer to the Yocto Scripts section below for more information}}
 
{{#switch: {{#var:HARDWARE_NAME}}
| DART-MX8M = {{#lst:MCUXpresso|M4_LINUX_DEMO}}
| DART-MX8M-MINI = {{#lst:MCUXpresso|M4_LINUX_DEMO}}
| VAR-SOM-MX8M-NANO = {{#lst:MCUXpresso|M4_LINUX_DEMO}}
| DART-MX8M-PLUS = {{#lst:MCUXpresso|M4_LINUX_DEMO}}
| VAR-SOM-MX8 = {{#varexists:SOC_HAS_SCU||{{#lst:MCUXpresso|M4_LINUX_DEMO}}}}
| VAR-SOM-MX8X = {{#varexists:SOC_HAS_SCU||{{#lst:MCUXpresso|M4_LINUX_DEMO}}}}
| #default =
}}
}}
 
<section begin=M4_LINUX_DEMO/><includeonly>
== Running a demo from Linux ==
 
The Linux remoteproc framework can be used to load the Cortex {{#var:CORTEX_M_TYPE}} firmware from Linux userspace.
{{#switch: {{#var:HARDWARE_NAME}}
| DART-MX8M-PLUS =
{{Note|'''Note:''' As of 7 October 2024, [https://www.nxp.com/docs/en/application-note/AN5317.pdf NXP Application Note AN5317] states the following:<br><br>
On i.MX 8M platforms, "remoteproc" stops only the Cortex-M CPU, not the Cortex-M system. Therefore, any in-flight Cortex-M bus transactions would hang after the CPU is halted and this can only be resolved with a full SoC reset. It is not recommended to stop the Cortex-M7 CPU in a production system. If the system must stop the Cortex-M7 CPU, reload the image and restart it. Then, the Cortex-M7 CPU must be in the WFI state and have no external access to the Cortex-M7 TCM memory through eDMA or other similar transactions. A possible solution is to implement a handshake between the Cortex-M and Cortex-A CPUs to confirm that the Cortex-M CPU is safe to stop or reset.}}
}}
{{Note|'''Note:''' The Linux remoteproc framework is not supported by all Yocto/B2Qt/Debian/Android releases.}}
 
Follow these steps to verify the Linux remoteproc framework is supported for your release:
 
# Select the software release from the [https://variwiki.com/index.php?title={{#var:HARDWARE_NAME}} {{#var:HARDWARE_NAME}}] software overview page.
# Click on '''Release Notes'''.
# Look for the '''Cortex {{#var:CORTEX_M_TYPE}} Linux remoteproc support''' row in the release notes to see which version is supported. If '''Cortex {{#var:CORTEX_M_TYPE}} Linux remoteproc support''' is not in the release notes table, the Linux remoteproc framework is not supported.<br><br>
 
After confirming Linux remoteproc support, follow these steps to use the framework:
 
{{#switch: {{#var:HARDWARE_NAME}}
| VAR-SOM-MX8X =
| VAR-SOM-MX8 =
| Boot Linux after following the steps in [[#Running a demo from U-Boot]]
}}
 
Increase kernel loglevel while debugging:
 
# sysctl kernel.printk=7;
 
Check the state of the {{#var:CORTEX_M_TYPE}}, it should be running already by U-Boot
 
# cat /sys/class/remoteproc/remoteproc0/state
 
If the state is 'running', stop the {{#var:CORTEX_M_TYPE}}
 
# 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
 
{{#switch: {{#var:HARDWARE_NAME}}
| VAR-SOM-MX8X
| VAR-SOM-MX8 =
  {{note|If remoteproc is used to reload ddr firmware, special disable_cache firmware must be reloaded between stop and start<br>For Example:<br>
# echo cm_rpmsg_lite_pingpong_rtos_linux_remote.elf.ddr_debug > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
# echo stop > /sys/class/remoteproc/remoteproc0/state
 
# echo cm_disable_cache.elf.debug > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
# echo stop > /sys/class/remoteproc/remoteproc0/state
 
# echo cm_rpmsg_lite_str_echo_rtos_imxcm4.elf.ddr_debug > /sys/class/remoteproc/remoteproc0/firmware
# echo start > /sys/class/remoteproc/remoteproc0/state
# echo stop > /sys/class/remoteproc/remoteproc0/state
}}
}}
 
{{note|For Yocto Dunfell and newer, this process can be simplified using /etc/remoteproc/variscite-rproc-linux<br>
Please refer to the Yocto Scripts section below for more information}}
{{MCUXPRESSO_Yocto_Scripts_Demo}}
</includeonly><section end=M4_LINUX_DEMO/>


=Debugging a demo=
=Debugging a demo=
== JTAG Hardware==
The Cortex-M firmware can be debugged using a JTAG debugger. Variscite recommends using a Segger [https://www.segger.com/products/debug-probes/j-link/models/j-link-ultra-plus/ J-Link Ultra+], [https://www.segger.com/products/debug-probes/j-link/models/j-link-pro/ J-Link Pro], or [https://www.segger.com/products/debug-probes/j-link/models/j-link-wifi/ J-Link Wi-Fi] debugger. You may also need a [https://www.segger.com/products/debug-probes/j-link/accessories/adapters/9-pin-cortex-m-adapter/ 9-pin Cortex-M adapter] from Segger.


== JTAG interface==
== JTAG interface==


Cortex M4 debugging requires JTAG.
{{#lst:MCUXpresso_Platform_Customization|{{#var:JTAG_SECTION}}}}


{{#lst:MCUXpresso_Platform_Customization|{{#var:JTAG_SECTION}}}}
{{#if: {{#var:LMEM_CACHE_FILE}} |  
== Debugging DDR binaries ==
To debug DDR binaries, it is necessary to boot in U-Boot and disable LMEM cache before compiling the binary. This is done by disabling all of its corresponding lines of code inside the function void SystemInit(void) of the file devices/{{#var:LMEM_CACHE_FILE}}. An '''example''' of how to do this is shown below:
 
  void SystemInit(void)
  {
  #if ((__FPU_PRESENT == 1) && (__FPU_USED == 1))
    SCB->CPACR <nowiki>|</nowiki>= ((3UL << 10 * 2) <nowiki>|</nowiki> (3UL << 11 * 2)); /* set CP10, CP11 Full Access */
  #endif                                                /* ((__FPU_PRESENT == 1) && (__FPU_USED == 1)) */
  '''#if 0'''
    '''/* Initialize Cache */'''
    '''/* Enable Code Bus Cache */'''
    '''/* set command to invalidate all ways, and write GO bit to initiate command */'''
    '''LMEM->PCCCR <nowiki>|</nowiki>= LMEM_PCCCR_INVW1_MASK <nowiki>|</nowiki> LMEM_PCCCR_INVW0_MASK;'''
    '''LMEM->PCCCR <nowiki>|</nowiki>= LMEM_PCCCR_GO_MASK;'''
    '''/* Wait until the command completes */'''
    '''while ((LMEM->PCCCR & LMEM_PCCCR_GO_MASK) != 0U)'''
    '''{'''
    '''}'''
    '''/* Enable cache, enable write buffer */'''
    '''LMEM->PCCCR <nowiki>|</nowiki>= (LMEM_PCCCR_ENWRBUF_MASK <nowiki>|</nowiki> LMEM_PCCCR_ENCACHE_MASK);'''
    '''/* Enable System Bus Cache */'''
    '''/* set command to invalidate all ways, and write GO bit to initiate command */'''
    '''LMEM->PSCCR <nowiki>|</nowiki>= LMEM_PSCCR_INVW1_MASK <nowiki>|</nowiki> LMEM_PSCCR_INVW0_MASK;'''
    '''LMEM->PSCCR <nowiki>|</nowiki>= LMEM_PSCCR_GO_MASK;'''
    '''/* Wait until the command completes */'''
    '''while ((LMEM->PSCCR & LMEM_PSCCR_GO_MASK) != 0U)'''
    '''{'''
    '''}'''
    '''/* Enable cache, enable write buffer */'''
    '''LMEM->PSCCR <nowiki>|</nowiki>= (LMEM_PSCCR_ENWRBUF_MASK <nowiki>|</nowiki> LMEM_PSCCR_ENCACHE_MASK);'''
    '''__ISB();'''
    '''__DSB();'''
  '''#endif'''
    SystemInitHook();
  }
 
 
}}


==Debugging GUI==
{{#switch: {{#var:HARDWARE_NAME}}
| VAR-SOM-MX93=<!-- Hardware is VAR-SOM-MX93, no JTAG steps currently
-->| #default=<!--
-->==Developing with IAR Embedded Workbench ==


A detailed step by step procedure to debug using SEGGER J-Link 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:
NXP provides a detailed step by step procedure to develop and debug MCUXpresso firmware using IAR Embedded Workbench and SEGGER SEGGER J-Link. Please refer to [{{#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}}
  {{#var:SDK_PATH}}/freertos-variscite/{{#var:DOCS_FOLDER}}/{{#var:NXP_USER_GUIDE}}
==Developing with Visual Studio Code ==
{{#ifeq: {{#var:MCUXPRESSO_VERSION}} | 2.15.0 |
Visual Studio Code, which is freely available, can be used to develop and debug MCUXpresso firmware:
[[File:MCUXpresso-hello-world-10-hightlighted-rc.png]]
For a full guide demonstrating how to get started, please refer to {{Varlink|MCUXpresso_VSCode_extension|{{#var:RELEASE_PARAM}}|Development using MCUXpresso for VS Code extension}}
| 
Visual Studio Code, which is freely available, can be used to develop and debug MCUXpresso firmware:
[[File:Vscode_MCUXpresso_StoppedAtBreakPoint.png]]
For a full guide demonstrating how to get started, please refer to {{Varlink|MCUXpresso_VSCode|{{#var:RELEASE_PARAM}}|MCUXpresso Development with VS Code}}.
}}
{{#if: {{#var:SOM_CAN_SUPPORT_1GB_DDR}} |
= Add support to SOMs with 1GB DDR =
'''MCUXpresso''':
$ cd freertos-variscite
$ ./var_add_1GB_support.sh -b dart_mx8mp  # for DART-MX8M-PLUS
$ ./var_add_1GB_support.sh -b som_mx8mp  # for VAR-SOM-MX8M-PLUS
'''U-Boot''':<br>
Following the guide at the [[#Running_a_demo_from_U-Boot|Running a demo from U-Boot]] section above:<br>
Change "setenv m7_addr 0x80000000" to "setenv m7_addr 0x7E000000" (when running for DDR):
$ setenv m7_addr 0x80000000" to "setenv m7_addr 0x7E000000"
$ print ramsize_check
Check the cma_size related to the condition '''if test $sdram_size -le 1024; then setenv cma_size cma=xxxM;'''<br>
if the xxxM value is greater than or equal to 640M then change to 512M:
$ setenv ramsize_check 'if test $sdram_size -le 512; then setenv cma_size cma=320M; else if test $sdram_size -le 1024; then setenv cma_size cma=512M; else setenv cma_size cma=960M; fi; fi;'
Save the environment changes:
$ saveenv
'''Kernel''':<br>
In the file arch/arm64/boot/dts/freescale/imx8mp-var-common-m7.dtsi<br>
Change the following section:
    m7_reserved: m7@0x80000000 {
        no-map;
        reg = <0 0x80000000 0 0x1000000>;
    };
To:
    m7_reserved: m7@0x7e000000 {
        no-map;
        reg = <0 0x7e000000 0 0x1000000>;
    };
Build the updated dtb files:
$ make dtbs files
Then copy the generated *m7.dtb files to the /boot folder on the SD card/eMMC.
'''Filesystem''':<br>
In the file /etc/remoteproc/variscite-rproc.conf<br>
Change the following section:
    readonly CM_LOAD_ADDR_DDR="0x80000000"
To:
    readonly CM_LOAD_ADDR_DDR="0x7e000000"
}}
}}

Latest revision as of 13:47, 13 November 2024

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 may 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 card (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.

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

Demos pins

Default M4 pins used by the demos are:

Function Pin
debug UART (UART2) RX: J12.6 / TX: J12.4
GPIO (GPIO4_IO03) LED7 for DT8MCustomBoard 1.x
U43.2 / R228 for DT8MCustomBoard >= 2.0 (Use Oscilloscope to observe output signal)
I2C (I2C3) SCL: J12.18 / SDA: J12.20
PWM (PWM2) J14.3

Available demos

All of the Variscite examples are located under the following folder 

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

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

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.

Building Using Yocto

In Yocto Dunfell and newer, Variscite provides a Yocto recipe for building and installing firmware into the Yocto image. Note, the examples below apply to the original release of this recipe in Dunfell and thus some of the syntax (such as the overrides) may need to be updated for newer versions.

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 

# Yocto Hardknott and older
SRC_URI_remove = "git://github.com/varigit/freertos-variscite.git;protocol=git;branch=${MCUXPRESSO_BRANCH};"
SRC_URI_append = " <your Git repository>"

# Yocto Kirkstone and newer 
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: 

# Yocto Hardknott and older
CM_DEMOS_append = "rtos_examples/freertos_hello"

# Yocto Kirkstone and newer
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/

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

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 handle loading 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

Running a demo from Linux

The Linux remoteproc framework can be used to load the Cortex m4 firmware from Linux userspace.


Note: The Linux remoteproc framework is not supported by all Yocto/B2Qt/Debian/Android releases.

Follow these steps to verify the Linux remoteproc framework is supported for your release:

  1. Select the software release from the DART-MX8M software overview page.
  2. Click on Release Notes.
  3. Look for the Cortex m4 Linux remoteproc support row in the release notes to see which version is supported. If Cortex m4 Linux remoteproc support is not in the release notes table, the Linux remoteproc framework is not supported.

After confirming Linux remoteproc support, follow these steps to use the framework:

Boot Linux after following the 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

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


Debugging a demo

JTAG Hardware

The Cortex-M firmware can be debugged using a JTAG debugger. Variscite recommends using a Segger J-Link Ultra+, J-Link Pro, or J-Link Wi-Fi debugger. You may also need a 9-pin Cortex-M adapter from Segger.

JTAG interface

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.


Developing with IAR Embedded Workbench

NXP provides a detailed step by step procedure to develop and debug MCUXpresso firmware using IAR Embedded Workbench and SEGGER SEGGER J-Link. Please refer to online or in the following document: 

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

Developing with Visual Studio Code

Visual Studio Code, which is freely available, can be used to develop and debug MCUXpresso firmware:

Vscode MCUXpresso StoppedAtBreakPoint.png

For a full guide demonstrating how to get started, please refer to MCUXpresso Development with VS Code.

Retrieved from "https://variwiki.com/index.php?title=MCUXpresso&oldid=27485"
Latest Modules
Support
Variscite Support Center
Contact Support
Product Longevity
Product Compliance Policy
Blog
Variscite Training
Variscite Website
This page was last edited on 13 November 2024, at 13:47.

© 2024 Variscite. All rights reserved