MCUXpresso: Difference between revisions
No edit summary |
(→Building a demo: Add building using yocto) |
||
Line 142: | Line 142: | ||
=Building a demo= | =Building a demo= | ||
==Building Manually== | |||
For any demo just follow this steps: | For any demo just follow this steps: | ||
Line 206: | Line 208: | ||
}} | }} | ||
==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: | |||
{| class="wikitable" | |||
|- | |||
! 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/ | |||
=Memory types= | =Memory types= |
Revision as of 16:52, 24 February 2021
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 (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
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 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 |
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 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.
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/
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 uboot 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
Please refer to the Yocto Recipe section below for more information
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 |
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
Please refer to the Yocto Recipe section below for more information
Yocto Recipe
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 |
The recipe also 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-u-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 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