One of the biggest road blocks (beside of closed source) using the BLE (Bluetooth Low Energy) stack from NXP is that it requires expensive tools to compile and build the stack. The good news is that I have now the NXP BLE stack for the Mikroelektronika Hexiwear ported to Eclipse and GNU gcc build tools for ARM 🙂
I’m using the NXP FRDM-K64F board in several projects: it is reasonably prices, has USB, Ethernet, micro SD card socket and connectors for Bluetooth classic and Nordic Semiconductor nRF24L01+ 2.4 GHz transceiver:
But one issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues.
A new McuOnEclipse components release was long overdue, so I’m pleased to announce that a new drop is available with the following major changes:
- Segger SystemView library with kernel time reporting
- GenericTimeDate supports different hardware RTC devices
- Utility with little endian packet handling functions
- Shell Standard I/O handlers for USB CDC, Segger RTT and Bluetooth
- FreeRTOS and stack size reporting
- printf() support in Shell component
- Various small bug fixes and improvements
Playing with RFID and NFC is definitely fun :-), and they are everywhere! For a research project I’m exploring different RFID tags and solutions. I several types around for a long time, but never found the time to actually work on it, so last nightI thought I give it a try, and I have it working with GNU ARM and Eclipse, powered by the NXP FRDM-K64F board 🙂
This tutorial goes through the steps how to create a blinking LED application, using Kinetis SDK and Processor Expert, using the TWR-KL43Z48M board from Freescale (now NXP):
I kind of hoped that after “Why I don’t like printf()” and all my other articles about printf and semihosting, that topic would be 200% handled and I won’t have to deal with any more. Well, I was wrong and underestimated how the Kinetis SDK is interfering with semihosting. And I underestimated how many of my readers are still using semihosting (even as there are other and better alternatives), so I keep getting questions and requests for help. That’s ok, and I hope I can help :-).
So here is yet again another post about how to turn on semihosting with Eclipse, GNU ARM Embedded and the Kinetis SDK v2.0. This time with the FRDM-K64F board:
A new release is available on SourceForge, with the following main changes:
- Support for FreeRTOS and Cortex-M7
- Segger SystemView updated to V2.38
- Components for NXP Kinetis SDK V1.3
- Fixed bug in Wait component (register handling for GCC and ARM)
- FatFS supports FreeRTOS V9.0.0 with static memory allocation
- FreeRTOS shell and task list with static memory allocation
- Floating point conversion routines in Utility
- FreeRTOS component shows NVIC mask bits
My wife tells me that I have too many boards on my desk. That is only *partially* correct: there are many, but not *too* many. But I’m working on too many tasks, but that’s a different aspect :-). I’m using more and more the Kinetis SDK V2.0, and as a result of this I have multiple SDKs installed on my machine. Because with the SDK V2.0 I get a download for each device/board installed (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“). So my list of SDK folders is growing, as shown with the ‘New SDK 2.x’ wizard in Kinetis Design Studio:
The same time, the amount of free disk space is reducing. What if I could combine all these SDK’s?
I don’t know if it is the same for you. But for me, configuring the pins on these new ARM microcontroller is a challenge: Most pins can do multiple functions, such as be used as I²C, UART or GPIO pins.
Configuring the pins ‘by hand’ is difficult, error-prone and usually the first thing I need to do for a new project/device. NXP developed a new tool for this task and previewed it at FTF 2016. It is available now both as web (online) and desktop (locally installed) tool. At FTF it was possible to play with an engineering release: time to get my hands on the public release :-). And as more and more student projects will start using that tool for their boards, I better have a tutorial for it :-).
I’m using FreeRTOS in most of my applications. There were only a few exceptions where an RTOS has to be used in safety critical systems: there usually it is not permitted to use any dynamic memory allocation because this adds the risk that a memory allocation could fail at runtime because of memory fragmentation or memory leak. And FreeRTOS uses a dynamic memory (heap) for the task stacks and the RTOS resources including semaphore, mutex and queues.
This is now a thing of the past. This week a new FreeRTOS Version 9 was released which does not need any dynamic memory allocation anymore: it is possible now to build completely statically allocated systems with FreeRTOS :-).
The challenge with the selection of a microcontroller for a project is: which one has the required number of UART, I2C, SPI? Combine this with the desired package (48pins, 64pins? LQFN?), the needed FLASH and RAM size and then even the hundreds of available microcontroller shrink to a handful only. And many times I need to make compromises: such as I need two hardware I2C, but the microcontroller matching all my other needs has only one I2C hardware. So I might end up with bit-banging the slower I2C bus. Doable, but not ideal.
What is cool that some of the newer NXP Kinetis microcontroller come with an interesting hardware: FlexIO. A peripheral hardware which allows me to implement a custom protocol, including driving WS2812B (Adafruit NeoPixel) LEDs with a FRDM-KL43Z board:
In “Mother of Components: Processor Expert with NXP Kinetis SDK V2.0 Projects” I presented an approach how to use Processor Expert components with the NXP Kinetis SDK. This article is a tutorial how to create a blinking LED project with that approach, using McuOnEclipse Processor Expert components and the Kinetis SDK V2.0. As board the FRDM-K22F is used:
Unfortunately, now the NXP Kinetis SDK V2.0 does not include Processor Expert support (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“). But at the Lucerne University we are using more than 150 different custom Processor Expert components we would like to use with that new SDK. So how to make them working with the Kinetis SDK V2.0? Using a Processor Expert as “the mother of all components”:
Time is passing fast, and many components have been updated to make the compatible with the NXP Kinetis SDK V2.0. As a highlight, besides of FreeRTOS the following components are now usable with the NXP Kinetis SDK:
With Processor Expert projects it is very easy to change the heap and stack size: There is a setting for this in the Cpu component settings, under the ‘Build options’ tab:
As there is no Processor Expert in the NXP Kinetis SDK V2.0 (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“), how to do the same in a SDK V2.0 project?
The world is changing, and the say is “change is good” :-). In the software and API world, change very often means that a change results into something broken. So I had battled with semihosting working on the NXP Kinetis parts, only to find out that it does not work any more with using the latest version 2.0. The semihosting output e.g. with P&E debug connection remains empty:
So how to fix this?
It has been already two months after the Feb 2016 release, and so much things are going on, so a new release was overdue. Today I have released a new version of the McuOnEclipse components on SourceForge with the following main changes and features:
- Kinetis SDK v2 with Processor Expert: Now many components can be used even with the Kinetis SDK v2.0 even with the Kinetis SDK not having Processor Expert included.
- Updated Segger SystemViewer to v2.32a with post-mortem and static buffer support
- Updated Segger RTT to v5.10u and fixed an issue with interrupts on Cortex-M4
- FreeRTOS Thread Awareness with OpenOCD
See readme on SourceForge for the full history.
For my classes I had so far asked the students to install the Kinetis Design Studio (KDS) v3.0.0 and then apply several updates and upgrades available. NXP has now released the v3.2.0 of their KDS (Kinetis Design Studio):
The v3.2.0 is including all the 3.x.x updates in a single installation which makes things easier to start with. And it now works for Mac OS X “El Capitan” and the latest GNU ARM Eclipse plugins :-).