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.
As a standard procedure, I add some console functionality to my embedded applications. That way I have a command line interface and can inspect and influence the target system. One interesting hardware feature of ARM Cortex-M is Single Wire Output (SWO): it allows to send out data (e.g. strings) over up to 32 different stimulus ports, over a single wire.
In my first post about Segger Ozone (see “First Steps with Ozone and the Segger J-Link Trace Pro“) I missed the fact that it includes support for kernels like FreeRTOS. So here is how to show the FreeRTOS (or any other RTOS) threads with Ozone:
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 🙂
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:
Getting a board from a distributor like Farnell/Element14/Mouser (add your own distributor) means that chances are high that the default firmware on it is written years from now because the inventory has not been updated, or because boards are still produced with that original firmware (because of testing?). So what happens if I use board with a firmware developed pre-Windows 8/10 area?
It might work, but chances are high that the bootloader and firmware is not ready for the ‘modern age’, and as a result the board might be bricked. If you still have a Windows 7 machine around (I do!), you are lucky. If not, then you need to read this article….
Breakout boards are great: they allow me to explore functions quickly, without to build my custom board: all what I need is some wires and ideally a bread board.
More and more of my students are using Microsoft Windows 10 machines, and my computer has been upgraded to Windows 10 a couple of week ago too. From my work and experience, a new operating system causes always some challenges, and Windows 10 is no difference. And no, this is not about Microsoft vs. Apple vs. Linux, this post is about addressing a potential and painful problem which I have observed with Windows 10 machines, and to my understanding it could happen with any other operating system too. The problem is that somehow on several student machines the bootloader and OpenSDA application on their FRDM boards did not work any more.
Sometimes it is very convenient to load a new firmware to a board without the need for a hardware debugger. This is usually done with a bootloader. The NXP Freedom and Tower evaluation boards have on-board debug device/microcontroller (OpenSDA) which can load different firmware implementations like CMSIS-DAP/mbed, P&E Multilink or a Segger J-Link OpenSDA applications. Both mbed and P&E implemenations support to program the board with drag&drop: simply send a file to a virtual MSD (Mass Storage Device) to get it programmed. The latest Segger OpenSDA firmware has this ability added now too: Programming the board with a virtual MSD device:
3.5″ Diskette Drives are not widely used any more: CDs, DVDs, memory/thumb drives and downloads from the web are the usual distribution method these days for software. Back a few years ago, software was distributed on one or many 3.5″ diskettes, and even before that time on 5 1/4″ floppy disk drives. So what to do with all these not-used-anymore hardware? Play music with it 🙂
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 “Tutorial: Blinky with NXP Kinetis SDK V2.0 and Processor Expert” I used Processor Expert components with the NXP Kinetis SDK to blink some LEDs. This tutorial extends the earlier project and adds FreeRTOS.
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:
NXP FTF Tech Forum in Austin has been a blast! I’m running another FreeRTOS hands-on session (FTF-DES-N2048) this afternoon which yet again is fully booked. But we will squeeze in as many as possible from the waiting list.
One very exciting thing we are going to use is FreeRTOS thread awareness in Eclipse/Kinetis Design Studio: to see and debug the FreeRTOS threads in Eclipse using the Segger GDB and it will show the list of threads in the Debug view:
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:
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?