iMX RT. New Cortex M7

[ehughes]

https://www.nxp.com/products/microcontrollers-and-processors/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-rt-series:IMX-RT-SERIES

600Mhz Cortex M7 MCU - 40nm tech. 3 bucks in volume.

$80 dev board.   Lots of IO, audio interfaces, etc.     

[technix]

600MHz with DSP extension, seems to be a good Blackfin+ killer. Damn, I spent sp much time on BF706.
Also a potential iMX6ULL killer, which I also unfortunately spent quite some time on.

I don’t see this killing i.MX6ULL. This chip lacked a MMU and thus any support for Linux. Also i.MX6ULL have support for some peripherals.

[andersm]

This chip lacked a MMU and thus any support for Linux.

MMU-less support was merged into the mainline kernel quite some time ago. For example, there's already support for a few ST Cortex-M4 and M7 MCUs.

[ataradov]

MMU-less support was merged into the mainline kernel quite some time ago.

Too tedious to use and userland sucks.

[technix]

600MHz with DSP extension, seems to be a good Blackfin+ killer. Damn, I spent sp much time on BF706.
Also a potential iMX6ULL killer, which I also unfortunately spent quite some time on.

I don’t see this killing i.MX6ULL. This chip lacked a MMU and thus any support for Linux. Also i.MX6ULL have support for some peripherals.

I mean DSP usage. A wonderful chip with HS USB, SPDIF receiver, I2S, plenty of CPU power and very low price tag. I'm also looking at STM32H7, though the chip is not yet available. I ordered a board yesterday, and it should arrive in a week.
I would like to see a chip with complete programming framework without Linux and hence the need of external RAM.

I don’t think i.MX6ULL was ever intended to be used for DSP anyway. It is a Linux chip from the get go.

[technix]

This chip lacked a MMU and thus any support for Linux.

MMU-less support was merged into the mainline kernel quite some time ago. For example, there's already support for a few ST Cortex-M4 and M7 MCUs.

That is uClinux. Very few actual userland tool kits support it.

[ali_asadzadeh]

Thumbs up, it's been ages that we needed something like this, if I were NXP, I would have added a Radio to the chip too, BLE 5.0 and Wifi
I remember when there was Freesale they had rumours of Kinetis X series that they would make for 4-8MB of flash and 400MHz of speed, so maybe they changed them to i.MX RT
And where did you got the 3$ price tag for the Volume QTY?

[tszaboo]

Price comes from i.MX RT Series Fact Sheet
It is already listed at Digikay, 5.3 USD @ 240PCS, so far it seems to be the cheapest Cortex M7. Though, you need flash for it, and I am wondering how fast the code runs from external flash.
It is cheaper than NXPs own Cortex M4 offerings, which put them in a strange place. Also, kudos for the LQFP package. Good to see, that companies understand that sometimes we need high speed MCU without designing a 6 layer board.

[coppice]

This chip lacked a MMU and thus any support for Linux.

MMU-less support was merged into the mainline kernel quite some time ago. For example, there's already support for a few ST Cortex-M4 and M7 MCUs.

With the memory constraints of most M4 and M7 chips its more of a stunt to run uCLinux than a practical solution.

[JPortici]

Also, kudos for the LQFP package. Good to see, that companies understand that sometimes we need high speed MCU without designing a 6 layer board.

yeah, but without LCD interface and graphics accelerator i think PIC32MZ DA is still attractive for a low cost 2/4 layer solution, even if the chip is ~2.5x more expensive it still come in a 176-TQFP package with both FLASH and DRAM builtin
176 TQFP wouldn't have been much bigger...

[coppice]

It is cheaper than NXPs own Cortex M4 offerings, which put them in a strange place.

That's hard to really tell unless you've tried serious negotiations for high volumes. However, this new part has no flash. That really gets the die cost down.

[donotdespisethesnake]

There certainly is a gap between high end MCUs running an RTOS and low-end MPUs running with Linux. However, iMX RT seems to fall in the gap rather than bridge it. It doesn't really have enough either for practical MCU or Linux usage. Perhaps there are some real-time applications where a souped up MPU can be useful, or a cheap but crippled Linux-style MPU is useful.

Occasionally I have asked sales folk about some of their offerings that don't seem to fit anywhere, and the typical response is along the lines "because we can" or "a big customer wanted it".

I wonder about the external Flash. Parallel flash would eat up a lot of pins, serial flash would suffer problems with latency? Either way, getting deterministic behaviour might require some careful tuning.

[andersm]

MMU-less support was merged into the mainline kernel quite some time ago. For example, there's already support for a few ST Cortex-M4 and M7 MCUs.

That is uClinux. Very few actual userland tool kits support it.

I know. It can still be fine for eg. single-application devices.

With the memory constraints of most M4 and M7 chips its more of a stunt to run uCLinux than a practical solution.

You would obviously need external memory.

[ali_asadzadeh]

External Quad SPI flash is so damn chip, W25Q64FVSSIG is 8MB and it's under 0.5USD, I think we can extract the flash and execute in internal SRAM for best price and performance

[coppice]

Occasionally I have asked sales folk about some of their offerings that don't seem to fit anywhere, and the typical response is along the lines "because we can" or "a big customer wanted it".

There is almost always a big customer behind the development of silicon.

I wonder about the external Flash. Parallel flash would eat up a lot of pins, serial flash would suffer problems with latency? Either way, getting deterministic behaviour might require some careful tuning.

Deterministic behaviour goes out the window as soon as you have cache. Most M4 and M7 chips have cache, whether they have an external memory interface or not.

[tszaboo]

It is cheaper than NXPs own Cortex M4 offerings, which put them in a strange place.

That's hard to really tell unless you've tried serious negotiations for high volumes. However, this new part has no flash. That really gets the die cost down.

I am aware that volume pricing works differently. But in my experience, Digikey pricing is usually* a good indication for the expected volume pricing. External Flash is cheap, and interfaces, like QSPI doesn't even make the board more difficult.

Linux

CAn we stop with the Linux talk? It is obviously not for that, hence the no MMU. And because it is an M series chip. You can go and run your bloatware on something else.

[technix]

Also, kudos for the LQFP package. Good to see, that companies understand that sometimes we need high speed MCU without designing a 6 layer board.

yeah, but without LCD interface and graphics accelerator i think PIC32MZ DA is still attractive for a low cost 2/4 layer solution, even if the chip is ~2.5x more expensive it still come in a 176-TQFP package with both FLASH and DRAM builtin
176 TQFP wouldn't have been much bigger...

PIC32MZ DA with eDRAM runs proper, virtual memory Linux too, loading from an external QSPI Flash.

[technix]

Linux

CAn we stop with the Linux talk? It is obviously not for that, hence the no MMU. And because it is an M series chip. You can go and run your bloatware on something else.

At least in China everything is either bare metal or Android.

[coppice]

I am aware that volume pricing works differently. But in my experience, Digikey pricing is usually* a good indication for the expected volume pricing.

If you work in a big component vendor, and know the bottom line price of parts in high volume, Digikey prices start to look like random numbers.

External Flash is cheap, and interfaces, like QSPI doesn't even make the board more difficult.

Yep, and we can see more and more MCUs going down this route. I think the key question is whether we will continue to see these MCUs sold with pins for an external flash chip, or whether there will be a migration to MCMs.

[technix]

I am aware that volume pricing works differently. But in my experience, Digikey pricing is usually* a good indication for the expected volume pricing.

If you work in a big component vendor, and know the bottom line price of parts in high volume, Digikey prices start to look like random numbers.

External Flash is cheap, and interfaces, like QSPI doesn't even make the board more difficult.

Yep, and we can see more and more MCUs going down this route. I think the key question is whether we will continue to see these MCUs sold with pins for an external flash chip, or whether there will be a migration to MCMs.

At least one vendor (GigaDevice) is taking the fast lane on MCM approach. They are one of the major second-tier brands in QSPI to begin with, and now their Cortex-M chips are built with a QSPI and a MCU die in MCM setup.

[Boscoe]

SD3.0 with 200MHz SDR . Finally an MCU wot ha fast SD card speed!

[funkathustra]

Definitely adding a dev board to my next order. Thanks for the find!

Is it just me, or does this part seem fairly light on controls-heavy peripherals (timers, ADCs)? I didn't look at how many channels each FlexTimer has on this part (6 is standard, I believe?), but the raw number of independent counters seems pretty low.

I suppose this part is built more for really heavy-duty algorithm work --- audio phased-array / noise-cancelling, image processing --- than straight-up control?

I jump between Kinetis and STM32 parts all the time, and one thing I like about the F4s is all the freakin' timers they have. Working on a 6-axis motor driver board right now, and I can easily route all motor encoders into dedicated timers, along with PWM speed control, with extra channels to spare.

EDIT: the dev kit has, like, 15 GPIO pins on it. Everything else is dedicated to the CSI, LCD, and audio interfaces... suspicions confirmed?

[Sal Ammoniac]

I suppose this part is built more for really heavy-duty algorithm work --- audio phased-array / noise-cancelling, image processing --- than straight-up control?

I jump between Kinetis and STM32 parts all the time, and one thing I like about the F4s is all the freakin' timers they have. Working on a 6-axis motor driver board right now, and I can easily route all motor encoders into dedicated timers, along with PWM speed control, with extra channels to spare.

EDIT: the dev kit has, like, 15 GPIO pins on it. Everything else is dedicated to the CSI, LCD, and audio interfaces... suspicions confirmed?

For heavy-duty control, the best Cortex-M part is probably the Infineon XMC-4000 series. Very sophisticated and flexible timer logic, etc.

[diyaudio]

600MHz with DSP extension, seems to be a good Blackfin+ killer. Damn, I spent sp much time on BF706.
Also a potential iMX6ULL killer, which I also unfortunately spent quite some time on.

AD needs to wake up in this respect, the black series has long ago exceed its place, the whole involvement with Intel was great at the time. SHARC on the other hand still seem to be a die hard processor with excellent dsp performance.

 

[coppice]

600MHz with DSP extension, seems to be a good Blackfin+ killer. Damn, I spent sp much time on BF706.
Also a potential iMX6ULL killer, which I also unfortunately spent quite some time on.

AD needs to wake up in this respect, the black series has long ago exceed its place, the whole involvement with Intel was great at the time. SHARC on the other hand still seem to be a die hard processor with excellent dsp performance.

Despite the Blackfin being a dead end, they seem to have had a surge of design ins for various market segments in China over the last 3 or 4 years. I guess when you talk seriously to ADI about decent volumes the prices can get attractively low.

[mubes]

For heavy-duty control, the best Cortex-M part is probably the Infineon XMC-4000 series. Very sophisticated and flexible timer logic, etc.

Hmm...don't discount the LPC43 series, and specifically chips like the LPC4367. Those multiple CPUs are very useful indeed. In fairness it's not in the same league as this iMX RT thing though. LPC1549 is much underloved too...

Dave

[ehughes]

I have used the LPC43x series on several projects.    Good chip but the memory segmentation is a real pain. 

The LPC546xxx is a good choice as it has many improvements.    It is the same process technology but uses less power as NXP designed the chip with a new set of IC libraries.        There is more SRAM it is arranged in contiguous region.


I got an early iMX RT board.      The high end LPC line is going to be a tough sell.    This chip is awesome.   It is lower in price,.  Faster and consumes less power.

[mark03]

Any thoughts how this compares with STM32H7, apart from the obvious speed difference?  My initial reaction after looking over the rev 0 datasheet:

• 600-MHz part only available in 0.65-mm BGA; despite the crowing about four-layer boards, hand-prototyping will not be easy
• less SRAM than STM32H7, although more of it can be "tightly coupled"; given lack of flash, more would have been nice
• peripheral set hits a couple of high points, like the SD card controller, but otherwise pretty lackluster

In a part this fast it would have been nice to see some kind of DSP acceleration, besides the rudimentary SIMD in the CM4/CM7 instruction set.  ST has the DFSDM (CIC filters) as well as JPEG engine.  Nothing like that in iMX RT AFAICT.

I wonder which customers drove development of these.  All that horsepower, yet so cost sensitive, why?

Still waiting to be impressed by a 40-nm MCU...

[ataradov]

Any thoughts how this compares with STM32H7, apart from the obvious speed difference?

Looks like the price is a major thing. Also 2x USB HS with integrated PHYs is no small thing.

I don't think the lack of flash is a huge deal. QSPI flash will give very similar performance to internal flash with wait states. And you have a very cheap way to expand your flash size, if needed.

I wonder which customers drove development of these.  All that horsepower, yet so cost sensitive, why?

I'd say all the voice recognition gadgets. It is also a good way to take over M7 market, which is relatively new.

[tszaboo]

I wonder which customers drove development of these.  All that horsepower, yet so cost sensitive, why?

I'd say all the voice recognition gadgets. It is also a good way to take over M7 market, which is relatively new.

Dont you need a lot of I2S or similar audio interface for that? Like Alexa has 7 microphones inside, so you would need 4 I2S interface. But more is better, since the MEMS michrophones. I guess the lack of flash is simple. They realized, that costumers are going to place a flash anyway, to store images for the display or audio samples to be played.

The i.MX RT1050 is specifically useful for applications such as:
• Industrial Human Machine Interfaces (HMI)
• Motor Control
• Home Appliance

I wonder which customers drove development of these.  All that horsepower, yet so cost sensitive, why?

It goes into the market gap, where the R series supposed to go. You know, Application, Realtime, Microcontroller = ARM. And then the Cortex R has been forgot. Oh no, wait, there is the Hercules RM57x with very competitive, 38 USD @1K pricing.

[ali_asadzadeh]

Since volume pricing is around 3$, we can use them for general MCU replacement in most projects, unless ST come back with a cheaper and better 800MHz solution, and I'm sure they will come back on streets again in less than a year! this war is actually so good for us

Remember that ST has the 28nm node process!

[ataradov]

Dont you need a lot of I2S or similar audio interface for that?

Yep, and that's why they have FlexIO modules with 32+16 shift registers. I did not go into details on them, but it looks like just the thing for a lot of I/O.

[ataradov]

Since volume pricing is around 3$, we can use them for general MCU replacement in most projects

The minimum package size is 100 pins, may be a bit too much for a lot of applications. And there are a lot of Cortex-M0+ to Cortex-M4 MCUs that will fit this price, which may be better suited for applications without the need for the processing power.

[technix]

Any thoughts how this compares with STM32H7, apart from the obvious speed difference?  My initial reaction after looking over the rev 0 datasheet:

• 600-MHz part only available in 0.65-mm BGA; despite the crowing about four-layer boards, hand-prototyping will not be easy
• less SRAM than STM32H7, although more of it can be "tightly coupled"; given lack of flash, more would have been nice
• peripheral set hits a couple of high points, like the SD card controller, but otherwise pretty lackluster

In a part this fast it would have been nice to see some kind of DSP acceleration, besides the rudimentary SIMD in the CM4/CM7 instruction set.  ST has the DFSDM (CIC filters) as well as JPEG engine.  Nothing like that in iMX RT AFAICT.

I wonder which customers drove development of these.  All that horsepower, yet so cost sensitive, why?

Still waiting to be impressed by a 40-nm MCU...

I think this chip is intended to be used along with external SDRAM and QSPI, likely 64MB or 128MB of them each. This compensates for the lack of internal RAM anyway, but the board size is increased significantly.

[tszaboo]

Dont you need a lot of I2S or similar audio interface for that?

Yep, and that's why they have FlexIO modules with 32+16 shift registers. I did not go into details on them, but it looks like just the thing for a lot of I/O.

Well, it is certainly not advertised well. Also, the reference manual is 3500 pages, so it would take a while to fully understand what does what. Hence all the white papers and application notes they make for proprietary stuff, like this FlexIO. I guess their technical writers just need to catch up a little bit.

[ataradov]

I guess their technical writers just need to catch up a little bit.

Yes, even the 3500 page document has a lot of glitches and mistakes. They still sometimes use Verilog notation for numbers

[Sal Ammoniac]

For heavy-duty control, the best Cortex-M part is probably the Infineon XMC-4000 series. Very sophisticated and flexible timer logic, etc.

Hmm...don't discount the LPC43 series, and specifically chips like the LPC4367. Those multiple CPUs are very useful indeed. In fairness it's not in the same league as this iMX RT thing though. LPC1549 is much underloved too...

I did discount the LPC43 series because its peripherals, especially the ones critical for many control applications, such as the capture/compare units and PWM, are nowhere near as sophisticated and powerful as the ones on the XMC-4000 series.

[technix]

I guess their technical writers just need to catch up a little bit.

Yes, even the 3500 page document has a lot of glitches and mistakes. They still sometimes use Verilog notation for numbers

Their technical documents leak Veriog a lot... I still remember reading the i.MX7 reference manual and get confused by the clock tree structure, all expressed using graphs exported from Verilog.

[dav888]

Hi!
iMX RT indeed looks great, but quite surprised that they don't support LPDDR2/3, really hope this is a typo or something they'll add in newer versions.

I've been with Blackfin 52x for many years and lately the 70x (mostly because of the low power-consumption)...
the 70x series added ddr2 which was a big bottle-neck on the 52x series.. (still not LPDDR though..)

Blackfin definitely used to be the goto cpu for doing low-power/battery stuff when they first came out (and kind of still is..!). The drawback might in modern-times be their proprietary tool-chains, lack of good OS/driver support and only closed-source pricey 3rd part drivers... and also I get the feeling that ADI now has their focus on other things.

I think this is where NXP could actually make a huge difference if they just choose the right paths to ensure great support to the onboard hardware peripherals.

Curious to see NXP's plans when it comes to board-support, peripheral drivers and such (especially in the USB host/device space).



Another really weird limitation of the RT series is: Nand FLASH, with ECC handled in software, what?
since most vendors incl. Micron stopped doing On-Die ECC, new SLC NAND's (25nm and future) on the market now requires 25nm: 8-24bit depending on density.. So nothing you want the M7 to crunch due to the lack of hardware ECC in the nand controller...


/David

[mark03]

I don't think the lack of flash is a huge deal. QSPI flash will give very similar performance to internal flash with wait states. And you have a very cheap way to expand your flash size, if needed.

I recently did a brief survey of available QSPI flash devices and their characteristics, also looking at the emerging 8-bit-wide standards like HyperFlash etc.  What stood out to me the most were the power-consumption numbers.  My recollection from STM32 datasheets where they compare active power with/without flash was that the difference was fairly modest... 10-20%?  whereas most of these external flash devices seem to eat quite a bit more, closer to being on par with the entire MCU active power.  Is this mostly due to the increased capacitance of the external bus versus an internal bus?  In any case, it seems like a significant disadvantage for external flash, power-wise.  Maybe no one else sees these fast M7 parts as suited to low-power applications, but I do, as they use less juice than the application-processor alternative for similar compute performance.

I still think more SRAM is called for.  Even neglecting the internal/external-flash power-consumption differences, just the fact that we are now at 600 MHz means that the flash-vs-SRAM performance gap is growing, and ST already has a competing chip with twice as much SRAM as RT1050.  It looks like NXP intends to fill out this new family, so perhaps the chips coming next year will include some with 1+ Mbits.

Having now skimmed the reference manual a bit more carefully, I must say I am more impressed with the peripheral set than I was before.  Does anyone know what is expected in terms of vendor libraries?  Do NXP/Freescale's peripheral libraries tend to be any good?  or at least better than ST's?

I would still like to see some kind of DSP acceleration peripheral, akin to ST's DFSDM.  Or, if NXP really wants to blow us away, they could provide an optimized software DSP library to replace or re-implement the CMSIS-DSP API.  As other members of this forum have demonstrated, CMSIS-DSP is not very well optimized, and substantial performance gains (2x or better) are possible, but with no off-the-shelf library this is a difficult, time-consuming process.

[EarthLord]

Quite excited about this beast of a chip. For the power consumption, an important information is the time required to wake up from the various sleep modes. I couldn't find this info scouring the datasheet and the application notes. Any luck for others?

[alexyzhov]

This series is designed by NXP Suzhou Development Team in China, and luckily I know some guys who are responsible to wrote documents about IMXRT, like user guide and application notes.
RT series are just like a kind of redesigns from imx6ull series, after changing the core into M7 from A7, with most peripherals have no change. The 96Kb internal ROM storages a bootloader just acts the same as the bootloader on IMX6 series.
More RT series chip will be released in the following years, like RT with up to 5MB onchip SRAM and 1Ghz M7 core, or some type with high-speed internal flash. Also, these high perfomance type will be fabricated by 28nm node.
They are working on supporting more FLASH devices these days, and more documents about developing IMXRT will be released before 2018.

[mac.6]

The code part should be reusable, but you will need the include file for the IMX6ULL, given that it's an 1.8MB header file for RT1050 prepare for a lot of work if you do it by hand (it's autogenerated)...

[nctnico]

RT series are just like a kind of redesigns from imx6ull series, after changing the core into M7 from A7, with most peripherals have no change.

Thanks. That's very good to know. I'm actually working on a design based on 6ULL, but I would like to get rid of Linux. Is there any possibility that I can have access to peripherals of 6ULL (namely, SPDIF, I2C, SPI, Ethernet, USB) with LPCXpress libraries of IMX.RT?

If you want to go bare metal I'd stick with the 6ULL and use the bootloader as the platform. Uboot has support for a lot of peripherals and filesystems. Just no OS like scheduling but if your main application doesn't need that it isn't a problem.

[krho]

nuttx?

[natester]

I’m also thinking about this, anyone know what kind of effort this would be to port to nuttx?

[dav888]

+1

but I'm more leaning towards https://www.zephyrproject.org as the rtos of choice

mainly because:
- it's linux like, similar way of configurating, supports .dts and such
- apache2 licence
- CMSIS
- Linux Foundation behind it + great people involved that used to do kernel drivers for linux in the past
- no IDE "dependency"
- NXP is somehow involved (at least for the Kinetis)

/d

[drojf]

I saw the 'mcuoneclipse' guy posted his experience/a tutorial with the 1050 devboard. Useful if you're interested in purchasing one, or want a well documented walkthrough for setting things up:

https://mcuoneclipse.com/2017/12/16/mcuxpresso-ide-v10-1-0-with-i-mx-rt1052-crossover-processor/#more-22907

[glenenglish]

@Blueskull, If you want an alternative to linux, FreeRTOS is a no brainer.
has lots of goodies for essentially zero interrupt latency processing, jump on return deferred procedure calls etc.
all the good stuff u need for microcontroller things....

and the companion TCPIP stack is rock solid.

I went IMX6ULL in a recent project...couldnt wait for STM32H7.

[patacongo]

I am planning the NuttX port now.  I have some other things on my plate so it is a few weeks before I get started.  Maybe some lower cost boards will appear before then?

[patacongo]

I think the porting effort would be close to trivial.  Most of the NXP/Freescale family members are supported now and the Cortex-M7 support is mature.

[andyturk]

I think the porting effort would be close to trivial.  Most of the NXP/Freescale family members are supported now and the Cortex-M7 support is mature.

Porting NuttX? A friend of mine spent some time trying to get NuttX to work. The first speedbump was that it (apparently?) requires a customized toolchain. So off-the-shelf GCC or your garden variety IDEs won't work. I don't think he was pleased with the support/doc either.

I've never tried NuttX myself, and YMMV.

[mac.6]

Running nuttx is already non-trivial on supported board (to have something that work outside basics). So I guess porting it to new architecture/board is far from trivial.

[patacongo]

> I am planning the NuttX port now.

That port is complete and functional but still undergoing test now.  The next phase is more extended driver development.

> Porting NuttX? A friend of mine spent some time trying to get NuttX to work. The first speedbump was that it (apparently?) requires a customized toolchain. So off-the-shelf GCC or your garden variety IDEs won't work.

Like so much that you see on the Internet, that is complete misinformation.  I and most people use the ARM Embedded Toolchain.  There is a custom NuttX toolchain, but its use is purely optional

[drojf]

If anyone's still watching this thread, the I.MX 1020 series and evaluation boards are out (at least on Digikey) now. This is the variant in the LQFP100/144 package with lower specs.

I'm not sure when they came out - may have been just recently or a month ago.

[luiHS]

 
The RT1020 evaluation board is available from the middle of last month, I bought mine on June 14 at Mouser.

And recently it was possible to buy the RT1020 microcontroller in LQFP100, I bought the first units from Digikey on June 26, although it is currently available in more distributors like Farnell, and soon in Mouser. It is not known yet when the LQFP144 will be available.