Product selection help and Kinetis vs LPC

[scottm]

I'm considering the next upgrade step for a product family that currently uses the MK22FN1M0AVLH12 (Cortex M4F @ 120 MHz, 128 kB RAM, 1 MB flash, 64 LQFP package). The latest selector guide is more than two years old, though, and it's not the most convenient thing to read through.

NXP's own selector search seems to have gotten even worse than before. I can't find any place to search across product lines and it won't even let you select a minimum amount of RAM. For this sort of thing I usually go to Digi-Key or Mouser's search, since they're better about parametric searches across many products.

Last time I did that, though, I picked the MK22FN1M0AVLH12 and regretted it a bit later on when I found out that it's actually an older generation than the MK22FN512 and lacks some features - and it also doesn't get nearly as much attention in the documentation and examples department.

So can someone who's current on NXP products tell me what they'd recommend in a Cortex M4F or better core, minimum 120 MHz (but 150+ preferred), minimum 192 kB of RAM, with USB, 2 12-bit DACs, 3+ UARTs, 1 MB+ flash, and Ethernet in a package with leads? (We do high-mix, low-volume stuff so keeping assembly and inspection cheap and easy is important and BGAs are to be avoided.)

From a glance through the forum it looks like maybe the reason there's not a newer Kinetis guide is that NXP is phasing it out in favor of the LPC parts, so maybe I need to look at switching over. If anyone here has made that jump, can you tell me if there were any major gotchas? I don't look forward to redoing a ton of low-level code. Since some of the peripherals in the Kinetis line go back to ColdFire and HCS08 before that I have many years of experience with those peripherals and their quirks. I have years of fine-tuned custom driver code to meet my specific requirements and I have nightmares about finding out weeks into a migration project that some hardware quirk is going to kill the performance of my application.

I have a knack for picking parts and tools right before they're dropped in favor of something else, so I'm hoping to get some feedback beyond just what I can find in official NXP docs.

Thanks,

Scott

[nielsmalotaux]

It took me some time to find it, but I used this page to select the LPC5528 when I needed 8 UARTS:

Product Selector | NXP 

[bobpaddock]

The new $15 E1 board based on the LPC55S69 makes a compelling case for going that direction.
The people that build the R-Pi saw our industrial market as a 'hole' and decided it to fill it.

It keeps the same tool set, if you happen to like it.

https://electronics360.globalspec.com/article/15535/new-m33-based-developer-board-fills-a-gap-in-the...

OKdo E1 Development Board - OKdo 

[scottm]

Thanks. I've got an LPC55S69 evaluation board on the way to try out. It's cheaper than the MK22FN1M0 we're using now, considerably more powerful, and has most of the peripherals I need. I think combined with an SPI Ethernet transceiver like the ENC28J60 and an I2S DAC it'll do what I need. Not looking forward to rewriting all of the DMA code, and I don't see a scatter/gather mode, so I may have to rethink some things, but I'm sure it's feasible.

Scott

[mjbcswitzerland]

Scott

Note that the i.MX RT have the same eDMA as the K22 so such code is (more or less) identical.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[mjbcswitzerland]

Scott

If you stay with Kinetis you are looking at a K64 or K66 due to Ethernet.

The Kinetis parts are still strong but are reaching end of design-in life time slowly (they are almost 10 years old).

I went for the NXP i.MX RT (rather than LPC) mainly due to price and performance as upgrade route to Kinetis products, also due to the fact that they tend to have compatible peripherals (of newer generation) so Kinetis code can run on them to a high degree. In your case an i.MX RT 1021 may be suitable: https://www.utasker.com/iMX/RT1020.html
with HS USB (the same as in the K66), 256k RAM, 6 UARTs, Ethernet, 500MHz operation (including 500MHz zero-wait state RAM!), and various advantages such a double-precision FPU and price of $2.29 in quantity (compare with Kinetis K66 at $7.74 !!), LQFP144 housing.
DACs can be made with PWM modules.
They do need a QSPI flash to boot from [apart from 1064 which has a 4Meg. one on-board] (2MByte Flash, for example, adds about $0.40) but with 66MHz access is more than twice the speed of the Kinetis internal Flash (and expandable up to 64M+).
Since they are fairly new it will give a good 10 years of design in time, and it is simple to maintain projects that run on both Kinetis and i.MX RT parts, whereby after a little time with the newer ones the Kinetis ones start to feel quite prehistoric. The down side is that the i.MX RT (with incredible features) is rather more complex but uTasker users can run their Kinetis product code on the i.MX RTs with almost no effort or learning curve due to a compatible HAL layer.

If you are very open minded there are another 35 major semi-conductor manufacturers that supply interesting parts with Cortex cores, but I like to stick with NXP....

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[scottm]

Hi Mark, always nice to hear from you! That's good to know about the i.MX RT. I've seen Erich post about it on his blog but haven't ever looked at it very closely.

I'm a little hesitant to jump to a device that requires a big increase in BOM count, but I realize for something with wired Ethernet some extra parts and board area are inevitable. For the last few years I've been working on fewer, bigger projects so it's not as critical to keep board complexity down. I might have to pick up one of the development boards and give it a try.

Do all of the i.MX RT parts support XiP? How have you found the performance to be? Any increase in EMC issues compared to internal flash devices?

Thanks,

Scott

[mjbcswitzerland]

Scott

The older Coldfire V2 parts (like 52235) had internal Eth + PHY are were very popular, even if they did get a bit hot. Integrated PHY has gone out of style now but I think that TI still have some parts still with everything internal.

All i.MX RT have XiP (and on-the-fly decryption), however I have avoided using this because it is faster to load code from there to internal RAM and then run at 500..600MHz zero-wait state with no QSPI power consumption or radiation. Since the uTasker project is very streamlined the biggest code that I have used is 118k in size (with Ethernet TCP/IP, USB RNDIS host stack) so still allows 128k RAM for variables and buffers. It costs little to move from a 1021 up to 1062 to get 1Meg RAM if big code sizes are needed. The FlexRAM is interesting since it can be dynamically allocated between optimal close couple instruction memory and optimal close coupled data memory so my boot loader does this based on the program site in QSPI flash - decrypts it to SRAM and allocates remaining memory for data.
More details in chapter 13 of https://www.utasker.com/docs/iMX/i.MX_RT_1021_uTasker.pdf
Boot loader flow chart: https://www.utasker.com/docs/iMX/Loader.pdf
and video https://www.youtube.com/watch?v=2XfgZq19XDw&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe&index=3
Simple building of complete boot loader and application in MCUXpresso (for RAM, SDRAM, Xip, on-the-fy XiP) https://www.utasker.com/docs/iMX/MCUXpresso.pdf

So essentially all operation can be internal and full security loading and OTA is in the concept and doesn't need to be an after-thought.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]

P.S: Also take a look at the Teensy 4: https://www.utasker.com/iMX/Teensy_4_0.html / https://www.pjrc.com/teensy-4-0/
These are about 1cm x 2cm and believe there is an SD card/Ethernet shield showing how little space practical products need.

[scottm]

Hmm, I suppose XiP's not going to like it if you tie up the flash with erase operations, so I'd still need to either have a second flash chip for general storage (including the file system) or run everything from RAM.

My code size is somewhere around 400 kB for this project, and that's with much of the TCP/IP stack running on a separate module. The performance-critical parts (mostly DSP code) wouldn't take up a ton of RAM, but there's a lot of infrequently-used stuff (including the entire command shell, text editor, OTA update process, etc) that I'd hate to waste RAM on and would be good candidates for placement in slower memory.

The way this project is shaping up, it'd be a shame to not have a more capable platform to let the code stretch its legs. The big problem with the current design is that it's married to a particular (deprecated) SiLabs WiFi module, which was fine when WiFi was mostly used for initial setup and fairly light-duty use. It's getting a heavier emphasis on network features now, and a mostly-abandoned, not terribly reliable WiFi module is just going to create headaches.

So that means planning ahead for a successor that can incorporate the existing features and also handle the extra overhead of the rest of the network stack. And unfortunately that includes having to cram a TLS-capable HTTP server in there, because browsers are getting more picky about security - you can't even enable the mic input on Chrome if the page isn't served up over HTTPS. This device's main job is handling 2-way radio interfaces and VoIP connections so being able to get audio in and out of a browser via WebSockets is important.

Where would I find information on how uTasker can be used in combination with FreeRTOS? Getting off FreeRTOS completely would take some work. Or would you say uTasker's RTOS is worth ditching FreeRTOS for? I don't feel like I'm pushing FreeRTOS too hard at this point - my most complex project has maybe 8 tasks, around a dozen queues, direct-to-task notifications, and a handful of semaphores.

The MK66FN2M0VLQ18 looks like the simplest way forward at the moment. Might not be the most bang for the buck, but if I ever want to actually finish the project I probably shouldn't make a major platform jump right now.

Got any Ethernet PHYs you like, preferably not in a QFN?

Thanks,

Scott

[bobpaddock]

If you are concerns about slow Flash then take a look at the 

Renesas RX family, which is their own core.
Their RA family may have fast Flash in the ARM core line, I am not sure.

Their SOBT energy harvesting parts are Interesting in themselves if you need low power (doesn't sound like it).

https://www.renesas.com/us/en/products/microcontrollers-microprocessors.html 

[jingpan]

Hi Scott,

You can search product longevity at here. Product Longevity | NXP 

K66 has 15 year life cycle from May 2015. So, that's not a problem.

But I agree with Mark that i.mxRT is a very good candidate. It can bring you to a new world. Flash storage is not a big problem, customer can get around it in may ways. It share IDE and may peripherals with Kinetis. NXP is building a demo library for i.mxRT.  Customer will see far more demos than kinetis.

Regards,

Jing

[jingpan]

Hi Scott,

Sorry for the inconvenience. 

There is no plan to phase out kinetis. New K32 series is on the way. And the SDK is still being update.

Please see MK66FN2M0VLQ18. It can meet all your requirement.

Regards,

Jing

[scottm]

What's new in the K32 series? Any parts in LQFP packages? Any chance NXP has something on the way to rival Microchip's SAM S70 line? I can get a 300 MHz Cortex-M7 with 2 MB flash and 384 kB RAM in a 64-pin LQFP for less than I'm paying for the K22FN1M0. I'd rather not have to learn a whole new tool set, though.

The MK66FN2M0VLQ18 is the part I found through Digi-Key's search, but my concern was that it appears to be a 5 year old part and it wasn't clear to me where it is in its life cycle.

Thanks,

Scott