The ‘Black Magic Probe’ (or in short: BMP) is a very small and open source JTAG/SWD debug probe with a build-in GDB Server. I saw that probe referenced in different places, so I thought I try it out with a few of my NXP LPC and Kinetis boards:
The ARM mbed USB MSD bootloader which is used on many silicon vendor boards has a big problem: it is vulnerable to operating systems like Windows 10 which can brick your board (see “Bricking and Recovering OpenSDA Boards in Windows 8 and 10“). To recover the board, typically a JTAG/SWD programmer has to be used. I have described in articles (see links section) how to recover from that situation, including using an inofficial new bootloader which (mostly) solves the problem. The good news is that ARM (mbed) has released an official and fixed bootloader. The bad news is that this bootloader does not work on every board because of a timing issue: the bootloader mostly enters bootloader mode instated executing the application.
The benefit of an IDE like Eclipse is: it makes working with projects very easy, as generates make files and it takes and automatically manages the make file(s). But sometimes this might not be what I want because I need greater flexibility and control, or I want to use the same make files for my continues integration and automated testing system. In that case a hand crafted make file is the way to go.
One thing does not exclude the other: This article explains how to use make files with Eclipse with similar comfort as the managed build system in Eclipse, but with the unlimited power of make files:
For many projects it would be cool to build a custom USB Joystick device, either as custom game controller for Windows or any USB host which can be used with a USB Joystick. Instead buying one, why not build my version? All what I need is a USB capable board, some kind of input (potentiometer, push buttons) and some software, and I have my USB Joystick:
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….
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:
I’m using the FRDM-KL25Z in my classes, and that board is very popular: low price (<$15), reasonable features (48 MHz ARM Cortex M0+, 128 KByte of FLASH, 16 KByte of RAM), and many tutorials elsewhere and on McuOnEclipse :-).
For the next (Fall) semester I’m looking for alternative boards, and one is the Freescale (now NXP) FRDM-KL27Z:
I have been asked to provide a command line shell example for a bare-metal (no RTOS) application, so here we go!
Having a way to communicate to the firmware on a board is essential for most of my projects: it is simply, incredibly helpful and easy to do (see “A Shell for the Freedom KL25Z Board“). This tutorial shows how to add a simple command line shell to the NXP Freedom board which then can be extended as necessary.
From my earlier work to use the NXP Kinetis with openHAB (see “Controlling NXP Freedom Board RGB LED with openHAB and Raspberry Pi“) it was only a small step to control a 20x20x20 cm light cube with 256 Adafruit WS2812 NeoPixels: