Is K20 going to be supported?

[jrychter]

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.

[santiago_gonzal · Accepted solution]

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

[jrychter]

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.

[santiago_gonzal]

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:.

[jrychter]

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.

[StrongChen]

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.

[jrychter]

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.

[santiago_gonzal]

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

[jrychter]

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.

[santiago_gonzal]

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

[jrychter]

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.

[mjbcswitzerland]

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

[jrychter]

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

[mjbcswitzerland]

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

[mjg8t]

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%... 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. 

[jrychter]

I think I should explain why I thought that porting KSDK to the K20 (in my case, K20_50) was "way too much work".

I dug into header files first. There is a file called MK20D10_features.h (I started with MK20D10, but I don't know if this is the best choice — this is another issue, one needs to be very familiar with many Kinetis CPUs to know which one is closest to K20D50).

The file is about 3000 lines, of the form:

    #define FSL_FEATURE_SOC_RFVBAT_COUNT (1)

"Porting" means that one has to know what each acronym means, and then know if it exists on the target chip (and how many units exist). On one hand, this is not difficult work, it's just tedious and error-prone. On the other hand, there is a lot of work to be done here.

mjbcswitzerland​ — I am aware of uTasker, and I'm sure it fits many projects, but not necessarily all of them, and this discussion is not about uTasker. It's about Freescale supporting (at least barely) their own chips with their own KSDK, especially given that the "newer Kinetis chips" aren't necessarily direct replacements for "older" ones.

BTW, the question that arises is — is the lifecycle of Kinetis chips really only 2-3 years? I moved from MSP430 world, where chips that are easily >10 years old are supported by the latest releases of code development environments. And yes, I consider "lifecycle" of a microcontroller to be the period of time when vendor tools support the part. These aren't diodes we're talking about, so just producing them isn't nearly enough: without software SDKs the chips can't really shine.

Anyway — I'm assuming Freescale autogenerates these kinds of headers from a meta system description. I am still hoping that the company will take a step and at least provide a useful base for us. I would gladly accept an unsupported and unofficial K20D50 KSDK — but with at least the necessary base includes already present.

[mjbcswitzerland]

Jan

1. I don't mean to try to make this a uTasker discussion. Usually I try to keep a low profile in a forum dedicated to KSDK but sometimes it is frustrating watching people banging their heads against a wall rather than simply working around it (and sometimes I get linked in with a request to comment). uTasker is a tool to help and it can also help KSDK users if they don't want to use it as a fully standalone solution - although I maintain that is a viable solution or alternative for people who may find it easier and more efficient for their requirements.

2. I just downloaded the KDSK 1.3.0 and built the K60D100 USB-CDC IAR example - loaded to the tower board and checked that it worked.

3. I then ported this to the TWR-K20D50 board. It took about 40 minutes to get the project running on the board.

To do this I changed a few clock configurations to obtain 48MHz from an external 8MHz crystal (rather than running at 96MHz from an external 50MHz clock source).

I had to comment out the line of code

	/* MPU is disabled. All accesses from all bus masters are allowed */
	MPU_CESR=0;

in usb_dev_bsp.c as I has predicted in the last post (otherwise it hard faults there).

In fact I didn't have to modify any code with respect to the PLL register difference (also reported in the last post) because the code expects the user to do this manually (and know the difference - i.e. the code is very basic and doesn't automate such details); if I hadn't known this I may have lost some time.

Finally I didn't actually modify the interrupt vectors since the example hardy uses any and the ones it does are fortunately compatible.

Last of all I modified the RAM and Flash sizes in the linker script to suit.

Therefore, it took 5 lines of actual code to be modified - approx. as predicted.

However - it is a jungle, and requires a certain amount of general and also Kinetis-specific experience. I had the advantage that I could step through the K60 code and compare it to a K20D50 simulation code seeing that it was the first time that I had seen the particular source involved (the KSDK code is about 10x the size of what is actually needed since it attempts to encapsulate everything to make it HW independent (and also make it rather more difficult to follow in the process - you need to always keep an eye on whether the file is coming from a BSP, a general library, a general driver or a PSP driver).

What I did when I started was make a complete copy of the K60 device library for the original board to a new one (named TWR_K20D50M) and renamed the original headers and pre-processor includes to point to it (so that I could be sure that my copies were being used, where I did a couple of mods).

It is very convoluted and there is code repeated all over the place (each device has its own files although many are identical and so it means a lot of work in case of any bug fixes since the developer must remember to make the same fix in many files thoughout the entire framework). In fact a new board adds 150MBytes of (mainly repeated) code to be added to the framework!

I didn't copy all device drivers (which would probably normally be done) since in this case I could use the original K60 ones. Also normally one would make a new BSP for the board too but since there was only one line to comment out I just did it in the K60 BSP (and killed that one's USB operation of course).

So if you would like to get a team together to fill in some missing parts I can certainly help out, but don't forget that the same excercise has to be repeated for every board, every example, every compiler, so would need quite a lot of time to coplete and test in each case - probably that is why Freescale decided against it - a five line change for a new board really can take weeks of work in the long run and further explodes the support complication. But on the other hand - maybe showing how simple it essentially is (or should be) may motivate to generaly improve the concept a bit in future versions and even fill in some of the missing pieces with the freed up time due to the optimisation.

Regards

Mark

[mjbcswitzerland]

Hi

>>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

[santiago_gonzal]

Hi Jan,

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

Regards,

Santiago

[mjbcswitzerland]

Hi

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

[jrychter]

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!