i.MX RT600 Hardware Design – Part 2 of 3 – Flash Memory, Boot and Debug

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX RT600 Hardware Design – Part 2 of 3 – Flash Memory, Boot and Debug

Eli_H
NXP Pro Support
NXP Pro Support
1 0 3,425

This article will continue detailing a minimal configuration design that uses an i.MX RT685 crossover MCU.    In the first article of this hardware design series, I introduced the power supply architecture of the RT600 series and illustrated some of the package/PCB layout features of the VFBGA176 package.       I also introduced some of the specs I am working towards for the “Super-Monkey” module and will power some of my future real-time audio processing projects.

When starting with a new MCU, I almost always examine power architecture and device packaging as the topics are often interwoven.    Once I have a good idea of how to properly apply power to a part and under what PCB layout will look like, the next order of business is to understand boot-up and debugging.    Like power&package, boot&debug are also often interconnected. It is important to consider both topics simultaneously.   The RT600 series have additional design considerations as they are flash-less MCUs as the designer must add a flash memory external to part.      The flash-less MCU paradigm allows for flexibility in your design but can be challenging if it is your first experience with a flash-less MCU.

For the Super-Monkey project, I am electing to use a simple external memory configuration with common QSPI NOR flash.        In my use case, time-critical DSP algorithms will execute from fast internal RAM.     Boot functions and non-critical code can live in the external QSPI flash.      I feel this is a good tradeoff for cost, storage capacity and performance.    QSPI is now well established in the marketplace and NXP was the 1st to offer execute in place (XIP) technology over a quad SPI bus (QSPI or SPIFI).   This technology was introduced over 10 years ago with the LPC18xx and LPC43xx microcontrollers.   Since then, QSPI XIP has proven to be a very good choice for many applications.         It is very common for real-time audio/DSP code to have a reasonably small footprint and it can execute from the fastest internal/tightly coupled memories.    Most other system code requirements is well served by XIP from external QSPI (serial communications, USB, system tasks, etc.).     It is important to note that the memory controller in the RT600 has 32KB of cache.      A little bit a cache on XIP QSPI memory can go a long way to improve performance.   

NXP FlexSPI Flash Controller

 

Built into the RT600 is a special flash interface controller called “FlexSPI”.   FlexSPI supports access to Single/Dual/Quad/Octal flash interfaces through the internal AHB bus.     This means the CPU can access SPI memory as if it were normal memory mapped flash.   The details of the SPI transactions are handled by the FlexSPI controller.    FlexSPI enables a wide array of memories to be connected to the MCU.  With FlexSPI, designers have access to extremely dense flash memories and can use new flash devices as they become available.   Designs can be easily scaled to storage requirements as needed.   SPI memories are also easy to route on a PCB as there are fewer connections.   Chapter 33 of UM11147 details the FlexSPI controller and possible use cases.

Eli_H_0-1624292975796.png

Figure 1.  NXP FlexSPI Memory Controller.

The FlexSPI controller has two ports which can be further subdivided into two separate interfaces allowing a maximum of 4 QSPI devices if needed.     To support future designs, the controller implements a look up table (LUT) that allow command sequences to be altered.       It is also important to note that in additional to flash, there are now SPI base (p)SRAM devices in the marketplace allowing for RAM to be added as well.     

QSPI on FlexSPI Port A Configuration and Boot

 

The MIMXRT685-EVK  demonstrates use of the FlexSPI peripheral with two devices attached.    One being a high-speed octal pSRAM connected to port A and an octal flash connected to port B.   Note the “octal” interface.     FlexSPI supports up 8-bit transactions on a Double Data Rate (DDR) interface.   Octal devices are still quite new as compare to quad devices but offer a significant performance increase (4x between the increase data path and DDR interface).      I also want to note something important about the FlexSPI on the RT600.     There are two ports but port A can support higher speed transfer through an use of an additional DQS pin.   In the case of the RT685EVK, the pSRAM is wired to the higher speed port.  I do have to chuckle a bit when the terms “SPI” and “Octal” are combined.     These memory interfaces are now synchronously clocked parallel busses.     QSPI was a simple extension to traditional 1 bit SPI but has now grown from the simple “serial” use case. For the Super-Monkey, I want to demonstrate a simplified scenario.

There is one other detail important to the RT600 with regards to the FlexSPI connections: 

If you want to use all 8 channels of the DMIC interface,  FlexSPI B will not be available.  You must connect to FlexSPI A

I want all 8 microphone channels and wanted to make sure to clearly state this for anyone else considering the this scenario. Figure 2 shows how to connect a QSPI flash to the RT685.

Eli_H_0-1624295125705.png

Figure 2.  QSPI flash connection on the RT685.

As you can see, QSPI memory is simple to connect.    I am using a +1.8v flash device.  Typically, I arrange my schematic symbols to be group functions by power domain to reduce the chance of error.  In this case, VDDIO_0 will be powered by +1.8v from the PMIC.   I left the connections to DMICs highlighted so you can see the intersection with FlexSPI B.  MCUXpresso includes a pin tool that allows you to plan the device muxing/pinout to reveal any potential issues.  With every new hardware design, I create a skeleton MCUXpresso software project that gets included in my hardware design git repository.  The skeleton project’s sole purpose is to define all of my IO as I am working through the hardware design.  

Boot Configuration

 

Once the flash memory is connected, there are two questions I always ask.    How does the CPU know to boot from this external flash and how to do I program the flash? The RT600 series shares a legacy with the LPC family of microcontrollers in that there are a few “ISP” pins which control the boot process.    These pins are sampled at power up by routines in located in program ROM.     One of the features of the LPC family of microcontrollers are ROM boot functions/utilities to allow programming over serial interfaces.  The RT600 continues this tradition and boot configuration is simple to set up.

Eli_H_0-1624295318310.png

Figure 3.  Selecting FlexSPI Port A on the ISP Boot Pins.

For the Super-Monkey module ,  I elected to use three switches to control the boot pins.   Note that the ISP lines are in the +1.8v power domain.   Setting the switches appropriately will allow to FlexSPI port A to be used for boot code.   

Eli_H_1-1624295589639.png

Figure 4.  RT600 ISP Pin Connections

The RT600 user manual (Chapter 41) documents how the boot process functions in detail.

Programming and Debug

 

An important mode of the ROM bootloader in the RT600 is called “Serial ISP” which allow enables a PC/host to perform flash operations (and program OTP fuses) via interfaces such as UART or USB.   It is important to *always* allow this mode to be available in your designs.   It will save you lots of time and headache down the road.

Eli_H_0-1624296010196.png

Figure 5. Serial ISP Boot Mode.

Serial ISP can be your “escape hatch” when you are having issues or need a production programming/configuration interface.      At minimum, you should always provide access to the  UART lines on Flexcomm 0 (PIO0_1 / PIO0_2).

Eli_H_1-1624296109232.png

Figure 6. Serial ISP UART Pins

I cannot stress how important it is to have access to these pins!  In addition to the UART, I would also recommend having USB access as well.   The ROM bootloader enumerates a USB-HID device for access to the programming/test functions.    There are minimal parts required to enable the USB interface.   I always add some EMI filtering to the +5v VBUS line as well as some ESD protection to the D+/D- lines.

Eli_H_0-1624296269760.png

Figure 7.   RT600 Minimal USB Connections.

I do want to point out the minimal clocking configuration required by the ROM bootloader. A 24MHz crystal is required for correct USB operation. 

Eli_H_1-1624296301124.png

Figure 8.   RT600 Minimal Crystal/Clock Configuration.

I am not using the RTC and elected to not connect a 32KHz crystal.        For the minimal configuration scenario,   a 24MHz crystal is the path to quick success.

ISP Serial Boot Support Software

 

There are a couple of useful software tools to drive the serial ISP boot functions.    The first is a command line application “blhost”.     The RT600 reference manual has some examples of the different uses of blhost (see chapter 41).   blhost can program externally connected flash, discover timing parameters, and program internal OTP fuses.   It is a Swiss Army Knife that is very useful for testing, debugging and deploying your design.

The 2nd tool can be found in the open source community:

https://github.com/JayHeng/NXP-MCUBootFlasher

This utility is GUI application that wraps blhost to perform all the most common operations.  It supports the RT600 parts as well as all the other parts in the RT crossover family.  

Eli_H_0-1624296683194.png

Figure 9. Open Source MCU Boot Utility

blhost is an NXP support tool available at the NXP website and the NXP-MCUBootFlasher is an open source community project hosted on GitHub.

RT600 Debug

 

The last piece we need to look at is debug access.   The RT600 implements a standard ARM SWD interface.   On my 1st design revision with a new MCU, I always add the standard .050” ARM header for debug.    The only connections needed for a minimal configuration is SWDCLK and SWDIO.     Keep in mind that SWD trace IO are also available on the RT600, but I am choosing to use the simplest configuration.   The only extra feature I added was Serial Wire Output (SWO).  Once in awhile I will turn it on for streaming additional data through the debugger.  However, I found that simple SWD is often good enough.  I prefer to use Segger J-Link and their Ozone debugger but MCUXpresso can be used with a low-cost debuggers such as the MCU-Link.  There is quite a bit you can get done with simple 2-wire SWD and the available tools.

Eli_H_0-1624297090834.png

Figure 10.  RT600 Debug Connections

In additional to the standard 0.050" debug header, I always add Tag-Connect pads for debug access.   As the design progressed closer to the production build, the standard header can be added to the do not place list and the tag-connect header can be used if debug as needed.

Eli_H_1-1624299998944.png

Figure 11.  Tag-Connect SWD Cable

It should also be noted that the reset signal from the debug header may need a level translator.     The reset connection from the PMIC to the RT600 is in the always on +1.8v power domain.     IO Bank 1 in the Super-Monkey will be tied to a +3.3v rail.  A simple solution is to use a simple open-drain buffer to connect the reset line into the PMIC/RT600 reset.

Eli_H_1-1624297352698.png

Figure 12.  PMIC Reset Connection.

Once debug access is enabled, you have another method to program the flash on the FlexSPI port.    The MCUXpresso debugger as well as the Segger J-Link support programming of QSPI flashes as they implement programming algorithms for SFDP based flash devices.       When you are in a edit/download/debug loop, programming the QSPI via SWD is the quickest way to get code loaded.     The Serial ISP function in ROM is also available but it is better suited to loading of finished binaries for production, etc.

Wrapping Up

 

At this point I have all the core connections to bring up the RT600 Super-Monkey.   From here I just need to layer in my IO.     In the next article I will show the Super-Monkey module design and the PCB routing.  From there I will be sending the design away for fab and assembly.    Once the design is validated, I will shoot some video and put the design files in the open.   Stay tuned for more i.MX RT600 content!

 

Links:

Crossing Over With the i.MX RT600 Part 1 of 2

Crossing Over With the i.MX RT600 Part 2 of 2

i.MX RT685 Hardware Design 1 of 3 - Power and Package

i.MX RT685 Hardware Design 2 of 3 - Flash Memory and Boot Configuration

i.MX RT685 Hardware Design 3 of 3 - The SuperMonkey Design

i.MX RT685 SuperMonkey QSPI Bringup with MCUXpresso and Segger J-Link

Creating a Custom Zephyr Board for the i.MX RT685 SuperMonkey