Overview

In a development environment the MIMXRT1050-EVK board may be programmed via a JTAG/SWD interface or via RedBoot loaded from boot memory.

When debugging via JTAG, you may need to disable the default HAL idle thread action, otherwise there may be issues where the target fails to halt and the debugging session is unreliable. More details can be found in the Cortex-M architectural HAL. If you are debugging via SWD this should not be necessary. When using hardware debug we recommend that the board SW7 DIP switches are used to select SD card boot (ON OFF ON OFF). Without an SD card installed, this will have the useful side effect of causing the processor to pause in the ROM loader.

For debugging applications are loaded and then executed on the board via the debugger arm-eabi-gdb, or via the Eclipse IDE. The following describes setting up to use OpenOCD with GDB.

OpenOCD

To debug via OpenOCD the etc/openocd.cfg from the build install directory should be used. Running OpenOCD on a host connected to the board via a suitable cable should produce something similar to the following:

$ openocd -f openocd.cfg
Open On-Chip Debugger 0.11.0-2 (eCosCentric 2021-06-15)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : CMSIS-DAP: SWD  Supported
Info : CMSIS-DAP: FW Version = 1.10
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 0 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : clock speed 1000 kHz
Info : SWD DPIDR 0x0bd11477
Info : imxrt1050.cpu: hardware has 8 breakpoints, 4 watchpoints
Info : starting gdb server for imxrt1050.cpu on 3333
Info : Listening on port 3333 for gdb connections

When connecting via GDB, the following output will be seen from OpenOCD:

Info : accepting 'gdb' connection on tcp/3333

Initialising CPU...
force hard breakpoints
Note: Breakpoints limited to 8 hardware breakpoints

undefined debug reason 8 - target needs reset

JTAG Debugging

Both JTAG and ROM startup types default to output of all diagnostics information via LPUART1. The default communications parameters are 115200 baud, no parity, 1 stop bit. It is recommended that LPUART1 be accessed via the CMSIS-DAP port.

It is possible to arrange for diagnostics to be output via the JTAG connection and appear on the gdb console. This requires the configuration option CYGFUN_HAL_GDB_FILEIO in the common HAL package to be enabled. This has two sub-options, CYGSEM_HAL_DIAG_TO_GDBFILEIO_CHAN and CYGSEM_HAL_DIAG_VIA_GDB_FILEIO_IMMEDIATE, that are enabled by default when CYGFUN_HAL_GDB_FILEIO is enabled and both should remain enabled. In this case, when arm-eabi-gdb is attached to the PEEDI, the following gdb command must be issued:

(gdb) set hwdebug on

Eclipse users can do this by creating a GDB command file with the contents:

define preload
  set hwdebug on
end

This will be referenced from their Eclipse debug launch configuration. Using GDB command files is described in more detail in the "Eclipse/CDT for eCos application development" manual.

Installing RedBoot

Prebuilt RedBoot binaries are provided in the loaders/mimxrt1050_evk subdirectory of the eCosPro release installation. The host directory within this subdirectory includes the openocd.cfg OpenOCD configuration file used to load and execute RedBoot from on-chip SRAM such that the QSPI flash boot image can be programmed into the FlexSPI QSPI flash memory of the i.MX RT10XX boards.

Notes:

The IMXRT1050-EVKB hardware must be modified from its default (as shipped) HyperFlash configuration to enable QSPI access. This is documented in the relevant "MIMXRT1050-EVK Board Hardware User Guide". It involves removing and moving some 0 Ω resistors on the underside of the board. Detailed instructions for rebuilding and programming your own version of RedBoot may be found in the section called “Rebuilding and Installing RedBoot” below.

In one shell window, start OpenOCD as described in the section called “OpenOCD” above, replacing openocd.cfg with the OpenOCD configuration file loaders/mimxrt1050_evk/host/openocd.cfg provided within the eCosPro installation directory.

Within a second shell window, open a suitable terminal application and connect to the CDC-ACM device provided by the CMSIS-DAP debug USB interface.

Within a third shell window, as illustrated in the figure below, change to the loaders/mimxrt1050_evk subdirectory of the eCosPro release installation, run cksum to note the checksum and size of the QSPI boot image, and load the SRAM RedBoot ELF prebuilt image into the target using OpenOCD and GDB.

$ cd eCos-4.6.4/loaders/mimxrt1050_evk
$ cksum qspi_boot.bin
2434204827 74924 qspi_boot.bin
$ arm-eabi-gdb redboot_SRAM.elf
GNU gdb (eCosCentric GNU tools 7.3.0e) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
... elided ...
Reading symbols from redboot_SRAM.elf...done.
(gdb) tar extended-rem localhost:3333
Remote debugging using localhost:3333
0x2020c330 in hal_delay_us (us=100) at .../packages/hal/cortexm/arch/current/src/hal_misc.c:609
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x20209020
Loading section .text, size 0xc080 lma 0x20209028
Loading section .rodata, size 0x36f8 lma 0x202150a8
Loading section .data, size 0x634 lma 0x202187a0
Start address 0x20209028, load size 64948
Transfer rate: 42 KB/sec, 9278 bytes/write.
(gdb) cont
Continuing.

From the cksum result above you can see the checksum and size of the QSPI boot image which are 2434204827 and 74924 respectively. On the second shell window running the terminal application, RedBoot output similar to the following should appear.

RedBoot(tm) bootstrap and debug environment [SRAM]
eCosCentric certified release, version 4.6.6 - built 15:15:21, Mar 17 2022

Copyright (C) 2000-2009 Free Software Foundation, Inc.
Copyright (C) 2003-2022 eCosCentric Limited
The RedBoot bootloader is a component of the eCos real-time operating system.
Want to know more? Visit www.ecoscentric.com for everything eCos & RedBoot related.
This is free software, covered by the eCosPro Non-Commercial Public License
and eCos Public License. You are welcome to change it and/or distribute copies
of it under certain conditions. Under the license terms, RedBoot's source code
and full license terms must have been made available to you.
Redboot comes with ABSOLUTELY NO WARRANTY.

Platform: NXP MIMXRT1050-EVK (Cortex-M7)
RAM: 0x20200000-0x2027f000 [0x2021d748-0x2027b000 available]
     0x80000000-0x82000000 [0x80000000-0x82000000 available]
FLASH: 0x60000000-0x607fffff, 2048 x 0x1000 blocks
RedBoot>

RedBoot is now running on the NXP MIMXRT1050-EVK and may be interacted with through the terminal application. The RedBoot output shows the available RAM that can be used as a temporary load buffer for the RedBoot QSPI boot image. In the example above the space 0x2021c568-0x2027b000 is available. The flash can now be initialised using RedBoot with the following flash initialisation issued at the RedBoot> prompt within the terminal application.

RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Console baud rate: 115200
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0x607fe000-0x607fefff: .
... Program from 0x2027d000-0x2027e000 to 0x607fe000: .
RedBoot> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0x607ff000-0x607fffff: .
... Program from 0x2027e000-0x2027f000 to 0x607ff000: .
RedBoot>

Once the flash is initialised, as illustrated in Figure 303.4, “Loading RedBoot QSPI boot image into memory”, perform the following actions:

...
(gdb) cont
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x2020c330 in hal_delay_us (us=76) at .../packages/hal/cortexm/arch/current/src/hal_misc.c:609
(gdb) restore qspi_boot.bin binary 0x20220000
Restoring binary file qspi_boot.bin into memory (0x20220000 to 0x202324ac)
(gdb) cont
Continuing.

Within the RedBoot terminal, confirm the image has been loaded correctly into memory by performing a checksum of the memory region into which the QSPI boot image was loaded by GDB and compare these results with the results from the cksum application as illustrated in Figure 303.1, “Checksum of QSPI image and Execution of RedBoot”. The RedBoot cksum command requires the base address of the memory region (0x20220000 as used above) as well as the size of the region (74924 in our example).

RedBoot> cksum -b 0x20220000 -l 74924
POSIX cksum = 2434204827 74924 (0x9117049b 0x000124ac)

As you can see the checksum values 2434204827 from both sources match. Instruct RedBoot to program the QSPI flash at location 0x60000000 with the image in memory:

RedBoot> fis write -f 0x60000000 -b 0x20220000 -l 74924
* CAUTION * about to program FLASH
            at 0x60000000..0x60012fff from 0x20220000 - continue (y/n)? y
... Erase from 0x60000000-0x60012fff: ...................
... Program from 0x20220000-0x20233000 to 0x60000000: ...................

At this point RedBoot has been programmed into the QSPI flash. The GDB session as well as OpenOCD must now be terminated using the ctrl-C keystroke combination in each window to interrupt and terminate the application. Assuming the SW7 is set to OFF, OFF, ON, OFF for QSPI boot selection then on the next hardware reset the system will boot the SRAM RedBoot from the QSPI copy automatically. The output illustrated in Figure 303.2, “RedBoot Output” will again be seen in the window executing the terminal application and normal interaction with RedBoot may again occur.

Finally, terminate the terminal application to release the CDC-ACM interface and enable both GDB and Eclipse to make use of the interface to download and debug user applications.

Rebuilding and Installing RedBoot

The following is applicable to any SRAM startup application that needs to be programmed into the FlexSPI QSPI flash memory and started from CPU reset, not just RedBoot. e.g. second-level boot loader or an application where all of its code and initialised data can fit within the SRAM space available.

See Notes: from the previous section.

A SRAM RedBoot application should be configured and built using the redboot_SRAM.ecm file provided in the packages/hal/cortexm/imx/mimxrt1050_evk/current/misc subdirectory of the eCosPro installation.

Should it prove necessary to rebuild a RedBoot binary, this is done most conveniently at the command line. The steps needed to rebuild the SRAM version of RedBoot are:

$ mkdir redboot_sram
$ cd redboot_sram
$ ecosconfig new mimxrt1050_evk redboot
[ … ecosconfig output elided … ]
$ ecosconfig import $ECOS_REPOSITORY/hal/cortexm/imx/mimxrt1050_evk/VERSION/misc/redboot_SRAM.ecm
$ ecosconfig tree
$ make

The standard make build process will create a binary version of the RedBoot application alongside the ELF version used for debugging. The install/bin subdirectory should contain the file redboot.bin which will be used when building the boot image. Create a QSPI boot image from this SRAM RedBoot binary as follows:

$ flashimg --qspi install/bin/redboot.bin install/bin/qspi_boot.bin

Notes:

Prebuilt host executables of the flashimg are located in the loaders/mimxrt1050_evk/host subdirectory of the eCosPro installation directory. Ensure these executables are either in the host's PATH or provide the full or relative path to the executable relevant to your host's operating system when executing the above command. The --qspi parameter is required to ensure the correct layout and contents of boot ROM descriptor structures to allow the application to be booted from the QSPI device. If using the prebuilt RedBoot images provided in the release, the filenames redboot_SRAM.elf, redboot_SRAM.bin and its flashimg derivative qspi_boot.bin within the loaders/mimxrt1050_evk subdirectory should be referenced in place of the files install/bin/redboot.elf, install/bin/redboot.bin and install/bin/qspi_boot.bin respectively in the examples below.

The simplest approach for installing the boot image is to use the onboard CMSIS-DAP debug interface and GDB to load the boot image into memory and use the SRAM RedBoot itself to initialise the flash. See the OpenOCD section for an overview of starting the necessary GDB server.

With a suitable terminal application connected to the host CDC-ACM device provided by the CMSIS-DAP debug USB interface (which is connected to the CPU LPUART1) the RedBoot output will be displayed when the application is executed.

Start GDB executing the SRAM RedBoot ELF image we have built:

$ arm-eabi-gdb install/bin/redboot.elf
GNU gdb (eCosCentric GNU tools 7.3.0e) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
... elided ...
Reading symbols from install/bin/redboot.elf...done.
(gdb) tar extended-rem localhost:3333
Remote debugging using localhost:3333
0x2020c330 in hal_delay_us (us=100) at .../packages/hal/cortexm/arch/current/src/hal_misc.c:609
(gdb) load
Loading section .rom_vectors, size 0x8 lma 0x20209020
Loading section .text, size 0xc080 lma 0x20209028
Loading section .rodata, size 0x36f8 lma 0x202150a8
Loading section .data, size 0x634 lma 0x202187a0
Start address 0x20209028, load size 64948
Transfer rate: 42 KB/sec, 9278 bytes/write.
(gdb) c
Continuing.

On the connected host CDC-ACM terminal, when the application is executed, output similar to the following will be displayed:

RedBoot(tm) bootstrap and debug environment [SRAM]
.. elided ..
Platform: NXP MIMXRT1050-EVK (Cortex-M7)
RAM: 0x20200000-0x2027f000 [0x2021c438-0x2027b000 available]
     0x80000000-0x82000000 [0x80000000-0x82000000 available]
FLASH: 0x60000000-0x607fffff, 2048 x 0x1000 blocks
RedBoot>

The RedBoot output will show the SRAM not used by RedBoot. We can use that space as a temporary load buffer for our boot image. In the example above the space 0x2021c438-0x2027b000 is available.

With RedBoot running the flash initialisation commands can be used at the RedBoot> prompt to setup the initial flash state.

RedBoot> fconfig -i
RedBoot> fis init

Once the flash is initialised, from the GDB session we can temporarily interrupt the executing RedBoot by using ctrl-C to halt the execution.

(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x2020c330 in hal_delay_us (us=76) at .../packages/hal/cortexm/arch/current/src/hal_misc.c:609
(gdb)

Where RedBoot is halted is not relevant.

The GDB command line can now be used to load the prepared QSPI boot image into SRAM that is not in-use by RedBoot. e.g.

(gdb) restore install/bin/boot_qspi.bin binary 0x20260000
Restoring binary file install/bin/boot_qspi.bin into memory (0x20260000 to 0x20270dd4)
(gdb)

At this point take a note of the length of the boot image loaded. In the above example it is 0x10dd4 bytes (0x20270dd4 - 0x20260000).

With the image loaded into SRAM we can simply continue the application from the GDB prompt to allow RedBoot to continue executing.

(gdb) c

With RedBoot running again we can now return to the RedBoot terminal with the RedBoot>> prompt, where the fis write command can be used to copy the boot image from the SRAM buffer and programmed into the flash from address 0x6000000 onwards:

RedBoot> fis write -f 0x60000000 -b 0x20260000 -l 0x10dd4
* CAUTION * about to program FLASH
            at 0x60000000..0x60010fff from 0x20260000 - continue (y/n)? y
... Erase from 0x60000000-0x60010fff: .................
... Program from 0x20260000-0x20271000 to 0x60000000: .................
RedBoot>

With the QSPI flash programmed the GDB debug session can be terminated, and assuming the SW7 is set to OFF, OFF, ON, OFF for QSPI boot selection then on the next H/W reset the system will boot the SRAM RedBoot from the QSPI copy automatically.