topic Re: Is K20 going to be supported? in Kinetis Software Development Kit

Is K20 going to be supported?

jrychter — Thu, 05 Nov 2015 09:48:29 GMT

I realize this is the kind of question that you really do not like to answer — but I will still try. I need to know if there are plans to support the K20 in the near future.

To provide some context, here is my situation right now: I have a number of projects which are space-constrained and price-sensitive (toys). Requirements call for USB and an M4 core, which narrows it down to the K2x line. I have prototypes based on the K20 (MK20DX128VFM5 to be precise).

I've been waiting for KDSK to support the K20, as it would make development much easier. But more than a year has passed, and not much has happened — I only have the base CMSIS peripheral access layer for the K20. In the meantime, K22F appeared, looking great, and seems to be very well supported. But the K22F is unusable, because of packaging. It is only available in LQFP or small-pitch BGA. LQFP packages are huge and simply won't fit, and those .5mm and 0.65mm pitch BGAs drive the PCB cost way too high. So the K22F is not a successor to the K20, it's something different. Also, few K22F chips are available now, and even the FRDM-K22F board isn't available at all in Europe until January or so.

So I am left in limbo — I don't know if I should just develop the code without KSDK, or wait. Going without the SDK is an expensive option. I need multiple peripherals, USB with MSD, FATfs, so it will take a lot of effort, which will be completely wasted once KSDK supports the K20. I'd rather not waste the effort. But then, I can't wait forever.

An ideal answer would be: please just wait for KSDK 1.4.0, which should be out before the end of the year.

A less-than-ideal but still better than nothing answer: the K20 is obsolete and will never be supported. Get used to those huge LQFP packages and the K22F, if you want to use the KSDK.

I would really appreciate some indications of what the plans are regarding the K20.

Re: Is K20 going to be supported?

santiago_gonzal — Thu, 05 Nov 2015 14:05:36 GMT

Hello Jan,

I'm afraid that K20 is not and probably won't even be supported. But you have tons of options supported with USB, and since you say you need FatFS and MSD, I guess you haven't started your development, so I will summarice your options:

- If you really want to stick with 32 QFN, you can have a look at MQX 4.x for K20. It has USB, Filesystem,etc...

- If you can afford going up in the number of pins, you have a very similar option to K20 in the K21A family, also at 50 MHz (Supported by TWR-K21D50). The issue is that the smallest package is 80 LQFP.

- If you don't mind going up to 120 MHz, which is better, you can use the K22 supported by the FRDM-K22, which has been available in Europe for a while now (I am in Spain, and several customers have ordered it through distributors since beginning of this year). I would recommend MK22FN256VLH12.

- If you don't need Cortex M4, and can fit your application in a Cortex M0+, you can go with the KL26/KL27, both fully supported in the SDK, and with up to 256 Kb of Flash (MKL27Z256VFM4).

Regards,

Santiago

Re: Is K20 going to be supported?

jrychter — Thu, 05 Nov 2015 15:26:18 GMT

Thank you for the definitive answer — it is very helpful (even though it isn't what I wanted to hear).

I would love to use the K22F. It's a great chip, and the crystal-less USB operation would lower costs and save board space. I could make good use of the floating-point, too. But let's look at the one you pointed to: it's a 100-LQFP. Together with pins and minimal required space on both sides we're looking at more than 20mm x 20mm footprint. For some wearable devices, I have boards that are less than 20mm in width. There is an LQFP-64, but even that is huge compared to a 32QFN. Why, oh why did you drop the very convenient QFN packages? They bridge the gap between prototype/hobby use and large-scale production, and are an attractive option for when one needs to save on PCB costs. Not providing QFN seems to be at odds with how you describe the intended markets for the K22F.

MK21 seems to be more expensive than K22F, while still having the same packaging limitations.

The L devices are probably not an option because of how much needs to run on the CPU.

I will have to rethink my options. Most complexity lies in software development, so perhaps I will have to accept larger devices because of the LQFP packages. Or perhaps Kinetis is not the right CPU for these devices.

In any case, thanks for responding and clarifying this.

Re: Is K20 going to be supported?

santiago_gonzal — Thu, 05 Nov 2015 17:09:33 GMT

Hello Jan,

So you need small packages...you should have said that earlier. Believe me, we do think more in large-scale production than in hobbists. Have a look at the attached picture :smileywink:.

Re: Is K20 going to be supported?

jrychter — Thu, 05 Nov 2015 18:06:59 GMT

Well, as I mentioned before — the WLCSP and MAPBGA packages are not an option for either hobbyists or small production runs with cost-sensitive devices, because of PCB cost. Being able to place those vias between 0.5mm pitch pads does not come cheap. And I believe you actually think *only* about really large-scale. For runs of hundreds to low thousands the cost of developing prototypes and then manufacturing PCBs with tolerances allowing WLCSP and MAPBGA (<0.8mm pitch) is simply not acceptable in many projects.

My point was that QFN provides a very good compromise: small package, which is useful at all scales and quantities, and allows cheap 2-layer PCBs with large tolerances. WLCSP and BGA cover the high end, while LQFP — well, I fail to see the advantages.

Anyway, many thanks for your time and answers. I hope you see my point now.

And on a related note: you mentioned that FRDM-K22F is available in Europe — any pointers? I checked Farnell (out of stock), RS (doesn't have it), Elfa/Distrelec (doesn't have it), TME (doesn't have it) and even Arrow lists it on back order.

Re: Is K20 going to be supported?

StrongChen — Fri, 06 Nov 2015 01:26:19 GMT

Hi Jan,

One possible option is to use K60 supporting resources on KSDK for K20 development. K20 and K60 have same die, they're totally compatible. You can also use K60 FRDM board to debug K20. Hope it helps.

Re: Is K20 going to be supported?

jrychter — Fri, 06 Nov 2015 08:57:03 GMT

Oh, thanks! That is a great suggestion!

But then it begs the question — if the K60 is supported, and if the K20 has the same die, why isn't the K20 supported as well? It seems it would not take a lot of effort to just support it out of the box.

Re: Is K20 going to be supported?

santiago_gonzal — Fri, 06 Nov 2015 09:38:31 GMT

Hi Jan,

I see your point totally, but the market is what it is, and QFN is not good for prototyping (not easy to solder manually) and is becoming a little big for consumer/wearables/sensitive to size applications. I'm sorry that the current package strategy does not fit your needs.

Regarding what Gang Chen says, it's partially true. K20 and K60 have the same die, only in the 100 MHz version. So if you use a 100 MHz K20, you can use Kinetis SDK and drivers, and in fact K20 at 100 MHz is supported in the SDK, you can create a new project with KDS and there are examples.

But there is no K20 at 100 MHz and QFN package, so there is no advantage in using a K20 at 100 MHz for you.

If QFN + USB is mandatory for you, your only option is K20. So you can either use MQX or port the SDK code to your device. Sorry that I can't help more.

Regards,

Santiago

Re: Is K20 going to be supported?

jrychter — Fri, 06 Nov 2015 14:25:44 GMT

Thanks for explaining. I understand your point of view.

I will point out, however, that I think that "QFN is not good for prototyping" is a myth, a leftover from old days. QFN is actually easier to solder manually than LQFP. These days there are plenty of cheap hot air solder stations, and soldering a QFN takes all of 15 seconds or so. It even self-positions better than large LQFPs.

I think many people avoid hot air for some reason and make their lives unnecessarily difficult this way :-) (similar to how many people tried to avoid SMD).

Anyway, thank you again for responding. I know what my options are right now and I appreciate the honest answers!

Re: Is K20 going to be supported?

jrychter — Mon, 09 Nov 2015 13:07:03 GMT

Santiago Gonzalez Fabian wrote:

If QFN + USB is mandatory for you, your only option is K20. So you can either use MQX or port the SDK code to your device. Sorry that I can't help more.

As I'm looking through the KDS tree, it just occurred to me that "porting the SDK code" myself might not be a bad option at all. It doesn't seem to be that difficult, especially given that a fairly similar platform (K20D10) is supported.

Re: Is K20 going to be supported?

santiago_gonzal — Tue, 10 Nov 2015 12:48:28 GMT

Hello Jan,

I would love to see the process and your progress.

As a help or guideline, you can check the attached PDF in ivadorazinova answer in this post:

Does KSDK support K60F120M device ?

Regards,

Santiago

Re: Is K20 going to be supported?

mjbcswitzerland — Wed, 11 Nov 2015 16:47:43 GMT

Just to point out for people that are flexible in their development environment:
- all* Kinetis parts are supported in the uTasker project (using KDS or any other IDE). It is also completely free for hobbyists and students, allows simulation of the parts/boards in (approx.) real-time.

- It contains industrial proven stacks (TCP/IP for Ethernet parts, USB for USB parts, dynamic low-power support, its own FAT, LCD library (for TFT, sLCD, GLCD) and an almost complete set of peripheral divers that adapt itself to almost all devices without needing any porting).

- It can be used together with KSDK to expand it or standalone to increase development efficiency and remove any restrictions to present device support or porting time loss.

- It also includes boot loader support for all parts: UART, USB, Ethernet, Kboot, USB-MSD device, USB-MSD memory stick, AN2295, so essentially allows compatibility with all FSL solutions and application notes but with many more features and mixing flexibility - again for complete Kinetis (K, KL, KV, KW, KE, KEA) parts without any porting required.

- Applications written for Kinetis parts can run on all types (assuming enough memory and the required peripherals) - from a KL03 to a K70 with a single code base.

- Applications written for Kinetis parts can also run on Coldfire V2 parts (with the same restrictions) or Coldfire V2 application can run on Kinetis parts.

See the link below for almost all Kinetis boards.

Regards

Mark

*Possibly excluding some that may have recently been introduced

Kinetis: http://www.utasker.com/kinetis.html

Re: Is K20 going to be supported?

jrychter — Mon, 23 Nov 2015 15:01:20 GMT

Ok, having taken a closer look (I actually started the modifications to see what needs to be done) this is way too much work. And it's really not about the complexity (things like memory map or interrupt vectors aren't that difficult), but about the sheer number of things that need to be changed. Just the number of acronyms in FSL defines is staggering, and many of those were new to me (and I've spent quite a bit of time with the K20 RM).

I think I will just consider K20 to be a legacy device, get rid of my K20 stock, and start using newer chips. I'm just worried — the main reason why I switched many projects to Kinetis uCs is because of the promise of a large, unified family with good support. It now seems that this is not how it's going to be: the K20 in my opinion is not old enough to just get obsoleted and sidelined. I am worried that the newer KL03, K02F and K22F chips that I'm switching to will encounter the same fate in a year or two: seemingly still available, but not really supported by the latest software that Freescale offers.

Re: Is K20 going to be supported?

mjbcswitzerland — Mon, 23 Nov 2015 15:40:43 GMT

Jan

Half the world works with the K20 so there shouldn't be any practical problems, as long as you are not hand-cuffed to a single software framework:

http://mcuoneclipse.com/2015/11/17/production-tinyk20-boards-arrived/

https://www.pjrc.com/teensy/teensy31.html

Regards

Mark

Re: Is K20 going to be supported?

jrychter — Thu, 26 Nov 2015 16:30:14 GMT

Mark,

Sure. But not everyone can afford to work with multiple software frameworks. I need to use one framework across the chips in the Kinetis line, I can't afford the fragmentation.

best regards,

--Jan

Re: Is K20 going to be supported?

santiago_gonzal — Thu, 26 Nov 2015 16:57:15 GMT

Hi Jan,

How many different Kinetis chips are you using today? Which of them do not fit your single framework requirements?

Regards,

Santiago

Re: Is K20 going to be supported?

mjbcswitzerland — Thu, 26 Nov 2015 21:22:32 GMT

Jan

As you already know, KDSK supports a sub-set of Kinetis devices and primarily the new ones.

If you need a single framework for everything you already "know" that KDSK will not do it for you unless you are willing to restrict yoursef to what it "can" do.

If you put enough pressure on Freecale they may invest additional development resources to expand the support to particular chips, or you could consider purchasing Freescale Professional Engineering Services (Professional Support and Service Resources|Freescale ) where needed to fill in gaps.

The K20 is available in 4 different and not fully compatible sub-derivates and your other option is to take a base (like the K60D100, which is in fact fully backward compatible with the K20_100 or the K60F120, which is fully backward compatible to the K20_120) and port this to the part that you need. The K20 is essentially a sub-set of the K60 (with a few fundamental, but quite small things that need to be tuned for the K20_50 and K20_72 parts). I have ported projects to all of these parts and it is in fact quite easy to do - there are actually only a handful of lines of code that actually need to be changed.

Regards

Mark

Re: Is K20 going to be supported?

mjg8t — Tue, 01 Dec 2015 18:25:42 GMT

I fully agree with Jan on all of these points. I too have the same requirement for using small/low cost highly functional MCU. The K20 32QFN is exactly this and it is a pitty that the subsequent K2x parts are not using the 32QFN package as it is, in my opinion, the best packaging option for cost sensitive small for factor applications. And they are as Jan mentions much easier to solder (hot air) than the TQFP packages. I too have keen watching the with hope that the k20/32QFN or follow-on part would come to market, but this post makes it pretty clear that this is not going to happen. Why oh why.

I do hope that freescale re-considers implmenting 32QFN or even 48QFN packages on newer part variants such as the "successor" k22f.

Re: Is K20 going to be supported?

mjg8t — Tue, 01 Dec 2015 18:39:43 GMT

Hi Mark,

I also would prefer to use KSDK as it scales very well to new devices and I would not have to worry about the longevity of utasker and I have hopes that the KSDK will implement more of the USB classes in the future, where it appears that only hid, msd, cdc are supported in utasker.

I would like to experiment further with utasker and I would be especially interested in any tips that you have might have regarding your previous statements and tips for creating support files for the MK20DN128VFM5.

Can you elaboarte on "there are actually only a handful of lines of code that actually need to be changed" In reference to the porting instructions given by freescale here:

https://community.freescale.com/servlet/JiveServlet/download/534940-298985/SDK%20Migration%20Custom%20Chip.pdf from this post:

Getting started with a K20 device

If freescale is not going to support the K20 in the mainline, maybe users such as jrychter, ken.sloat BlackNight(to support the "tinyk20")
, myself and others can help bring the MK20DN128VFM5 up to speed in the current KSDK?

Thanks for any support you would be willing to offer on this front.

Re: Is K20 going to be supported?

mjbcswitzerland — Wed, 02 Dec 2015 04:46:17 GMT

>>longevity of utasker

I heard this a lot in its 11 year history but it has out-lived the old Freescale Coldfire Interniche solution ad Luminary Micro's solution (after they were swallowed by TI) to name just two examples. The features from the Kinetis project are still being used by new Coldfire (mainly legacy hardware) products since it is compatible with all Kinetis and Coldfire V2s. It is also compatible with NXP Arm7 and Cortex M3/M4 parts in case the take over by NXP causes some (unplanned) upsets to the present direction......

>>only hid, msd, cdc

The uTasker project is driven by industrial requirements and integral parts of the framework are not "examples" but usually fully integrated results from industrial developments (after much testing in harsh environments and feedback/experience over several years of such operation in as many projects/products as possible). These three classes have been developed for such demands and other classes had rarely been requested. However, the latest version also supports initial host (OTG) which is being used in first products and virtual Ethernet/RNDIS and audio will be available shortly since demands in this area (and generally USB in industrial environments) has noticeably taken off in the last year or so.

Freescale offers KSDK, MXQ and PE (and a varietly of newer and older ANs - with or without compatibility with the device of choice) but these also have their strengths and weaknesses. Different solutions are suitable in different situations and no one will always be 100% "right". The uTasker solution attempts to fill in some missing gaps as well while being suitable for the highest percentage of real world requirements as possible, coupled with a solution that can run on really every part without porting investment.
So there will always be something missing - probably the way to go would be with Windows CE, Embedded Linux or Windriver when the highest availability of protocols, classes etc. are the highest requirement but then that would limit to a hand-full of Kinetis devices in the best case so again is far from a general solution.

What the uTasker adds are also simulation capabilities for project acceleration and learning, with as a focus on doing as much as possible with the least resources, simplicity and overall reducing real development schedules as much as possible. It is a further choice (to many others) and may or may not be most suitable for a certain requirement, but the probability is pretty high based on 11 years of experience with thousands of developments and products throughout the world.

>>tips for creating support files for the MK20DN128VFM5

This is where the concepts are different. The uTasker solution is a single project (it is like PE in a way but without the flashy GUI and with intensly tested and optimised code output). It has only one support file (or library) that is "Kinetis" which adapts itself to whatever chip is being used (when using a Coldfire just its support file/library is used instead).

KSDK is a collection of processor/board/projects which works out of the box for a few but needs the creation of new parts/projects for different ones. It also utilises various open source projects to supply stacks and such - the uTasker solution has also stacks but these were fully developed for the environment and typically have greater fetures/performance and are supported at source.

Also MQX is a huge array of projects and libraries - it can take 20 minutes just to move between two existing boards due to the various libraries that need to be build (BSP/PSP/drvers etc.).

Both of these are difficult and time consuming to support and still require often great efforts with debugging and code creation to add new parts or boards, including the necessary knowledge and experience (if it didn't there wouldn't be so many topics from professional developers discussing how and why they can't do it for weeks on end, rather than the same professional developer just spending a few minutes to solve it and getting on with productive work).

So my tip is not to do the steps in the guide for a real project for single use (if developing a new platform or general use then yes, one needs to do it due to the concept that is in place). I would simply take the K60 project and directly edit the content of its headers. The K20 and K60 are almost identical - here is more or less the full list of mods that are needed:

For example, I made some projects for Erich's new tinyK20 (a 50 MHz MK20DX128VFT5) - see: http://www.utasker.com/kinetis/tinyK20.html

which was done before the board had been produced and worked on first programming (thanks to Erich for sending a real-live board to verify on!!).

To do this I could simulate it (and check the operation and connections on the board in the simulator).

Since it is a 50Mhz part I activate

#define KINETIS_K20 and

#define KINETIS_MAX_SPEED 50000000

which controls the differences in its clocking limitiations (its clock module is almost identical apart from the divisor value to be used in its PLL - it has a different scaling to 100MHz or FPU parts). Otherwise it is just checing that no clocks are set too high.

The flash granularity in 50MHz parts is 1k and not 2k (as K60 or faster parts have).

Then it has some interrupts at different vector locations (the list of vectors needs to be adapted according to the vector table in the user's manual).

Periherals: 3 UARTs instead of 6, only 1 I2C, only 2 SPI, no I2S, only 2 FlexTimers, only 2 ADC, no RNG - but all obvious stuff and all 100% compatible. Maybe a couple of different pin mux locations but again no big deal.

When using USB its bus master needs to be set to 3 rather than 4 for the 100MHz K60. Also don't configure concurrent access in the MPU since the chip doesn't have one. (the only 2 lines of USB code that needs to be changed and only 1 if you don't need the USB controller to be able to transmit data that is resident in Flash).

#define KINETIS_REVISION_2

since its silicon is a revision 2 type - practically it means that

PMC_REGSC need to be reset after low power wakeups (although also newer K60s are rev.2)

and when reading reset causes it uses the newer MC rather than RMC. Plus a few older errata workaround may be disabled in newer silicon.

I don't see anything else needed so it should really be only a few lines of header file changes and removing some peripherals that aren't there (although also not needed as long as they are not accessed).

Erich certainly has projects for the 50Mhz K20 too although I see that he seems to have a preference for FreeRTOs (to add another resource that one should either "desire" to use or "wish to avoid" to the list) and even embedded Linux according to some recent blog entries.

Regards

Mark