The silicon shortage is still going on. While the NXP Kinetis KE devices might not be my first choice, they still seem to be available, in at least in lower quantities. This has been recognized by others, as I’m getting more and more questions and requests for the KE and KV family. This is why I un-dusted my old FRDM-KE02Z to be used with the latest MCUXpresso SDK and IDE.
And in case you want to use that board or device with semihosting, I have you covered.
Well, that continued silicon shortage seems to be especially bad for Kinetis (K family) and LPC devices, for example the popular LPC845. Mouser shows 100+ weeks factory lead time (yikes!). At least the price is showing up still the same, as one of our research partner had to pay 10x than usual for a different device, although for a small quantity.
Several readers of this blog want to build a MetaClockClock, but because lack of parts, they are mostly stuck. The option of course is to use a different part, and one of the few devices which are available are the ones from the Kinetis KE family. Probably because they don’t have much memory, and their pinout/package is not the most attractive one. But at least you can get some devices. In the worst case I can salvage parts from the evaluation boards which still are available in some quantities, that can help a project going.
I’m not saying that dusting off the KE (or KV) is always the right solution: They are very different from the K devices, and beside of the tools used they pretty much require rewriting most of the firmware because of the clocking and peripherals. Looking out further, there are interesting insights on a forum plus on Bloomberg why some devices seems to be more affected by the shortage than others. Ultimately, it means to move on to different devices?
So anyway, if you want to use the KE device with semihosting, here is how….
First, create a usual project with the NXP MCUXpresso SDK. I’m using here the NXP MCUXpresso IDE 11.5.0 and the SDK 2.10.0 for the FRDM-KE02Z40M board.
The first thing to make sure for semihosting is that the correct library is selected for the project:
To be able to use semihosting, the library needs to implement some ‘stubs’ translating the standard library I/O functions (putc, puts, printf, fopen, …) into the correct low level calls. The MCUXpresso SDK offers several variants of the library:
- none: no stubs are implemented
- nohost: stubs are ’empty’ and doing nothiing
- semihost: semihost stubs implemented
- nf (no file): semihosting without file support, so only for stdin, stdout and stderr
- mb (memory buffer): using more memory for faster speed
My general recommendation is to use the newlib-nano, because open source, small footprint and good performance.
From here on, you can use printf() or better puts() in your code, or anything else you want:
Oh wait! The reality is that with the default SDK template you might end up in a hard fault like this:
The Heap and Stack Usage view in above screenshot gives a hint about the reason:
One should know that semihosting and especially printf() or standard I/O operation could use lots of (dynamic) memory, see “Why I don’t like printf()“. Obviously 0 bytes is proably not good enough, so it seems that allocation of the standard descriptor failed.
The solution is simple (if you have enough memory): increase it. I increased it to 512 bytes in the linker settings:
With this, it runs fine for that test:
But just consider: this device has only 4 KByte of RAM, so semihosting with standard I/O support might not be the best thing. But for this, I might have you covered with a custom semihosting library not using such an amount of RAM? But that might be yet another article….
You can find the project used in this article on GitHub.
Happy hosting 🙂
- Project on GitHub: https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/MCUXpresso/FRDM-KE02Z/FRDM-KE02Z_Blinky
- A 5V Freedom Board? FRDM-KE02Z
- Semihosting (again!) with NXP Kinetis SDK V2.0
- Semihosting with Eclipse and the NXP Kinetis SDK V2.0
- Semihosting for Kinetis Design Studio V3.0.0 and GNU ARM Embedded (launchpad)
- Semihosting with GNU ARM Embedded (Launchpad) and Kinetis Design Studio
We are fully committed to the KE parts, using KE02Z, KE06Z, KE14F, KE16F, KE18F … they are also VERY hard to acquire in quantity; mind you so is everything else … Microchip just canceled a confirmed order of [thousands of] PIC parts, just a week before supposed delivery!
LikeLiked by 1 person
I don’t know how much I can trust delivery dates on Mouser and Co at all. But at least for some of the KE packages there are chips in lower (say less than 10 or 50) quantities available, unlike other parts where they are out for months (or a year) and delivery dates are out a year or so. I have been told that Mouser/etc seems to some inventory, but they put it on the shelf only in smaller quantities, to make sure that nobody can get them all. It is a very unfortunate situation for many of us :-(.
We had to redesign output circuits to not use ST drivers (which meant having to design over current protect). We’ve had to completely redesign multiple products from scratch with different processors.
Just now about to buy $200,000 of a new to us processor to replace those not available PICs (two fast days proving it can be a replacement!)
It’s all a challenge for sure!
LikeLiked by 1 person
We had to re-design multiple designs because the DC-DC converters were not available more. For other projects we are running out of Kinetis devices (we were lucky that we had some inventory). But inventory is running out, so looking into alternative MCU vendors, even considering using RISC-V or vendors from China. The good thing about this shortage is, that it is an opportunity for changing the way things have been done in the past.
LikeLiked by 1 person