The Hexiwear docking station would have a nice feature: it has embedded a debug circuit (OpenSDA). That way I would not need an external debug probe to debug the Hexiwear. However, a debug probe is required to reprogram the docking station itself:
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….
Sometimes things don’t go well, especially with bringing up a new board design. I always sweat blood that first minute when I try to connect with the debugger to a new design: Will it work? After the optical inspection, performing electrical tests (no shortcuts? voltage levels ok?) the inflection point is when I’m connecting the first time with the debugger to the new board: either it will properly connect and program the device (hurrah!) or it will fail and potentially difficult hours of investigations have to follow.
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.
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:
FreeRTOS is probably the number one RTOS used, and Eclipse is likely the most popular IDE I can think of. But debugging FreeRTOS applications with Eclipse and GDB is somewhat limited? What I would like to get at the minimum is this: ability to see all the different threads in the Eclipse debug view like this:
As you might guess from that screenshot: this post is about how to make FreeRTOS tread debugging possible with Eclipse and GDB :-).
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:
Many times it is very useful to debug multiple boards at the same time. For example if I’m debugging a communication stack between two boards: that way I can debug the protocol on both sides. Eclipse is a great framework which allows that. This post shows how to debug multiple boards (e.g. the NXP Freedom boards) in parallel from the same Eclipse IDE using GDB and the Segger J-Link:
When I create a project in Eclipse (e.g. in Kinetis Design Studio with the GNU ARM Eclipse plugins), I have to specify the name of the project during creation time:
But what if I change my mind later on and want to use a different name? How to rename the project?
It is possible to use the Freescale FRDM-KL43Z to debug another board (see “Using the Freescale Freedom (FRDM-KL43Z) to Debug other Boards“). The FRDM-KL43Z has an on-board debug probe integrated, the OpenSDA. But it is easily possible to debug the board directly with a SWD debug probe like the P&E Universal Multilink or the Segger J-Link.
In “CodeWarrior Flash Programming from a DOS Shell” I showed how to program a device from the DOS shell. Because that example was for ColdFire and CodeWarrior for MCU10.2, here is the same for a Kinetis (FRDM-KL25Z) and CodeWarrior for MCU10.6. In my workspace (c:\tmp\wsp_10.6) I have a project folder (FRDM-KL25Z).
I’m using the ‘Flash Programmer’ to sneak the needed commands:
This is Part 2 of a Mini Series. In Part 1, I described how to set up the hardware (see “Tutorial: Adafruit WS2812B NeoPixels with the Freescale FRDM-K64F Board – Part 1: Hardware“). Now it is time to have the software tools ready. In this post I describe to have the IDE (Freescale Kinetis Design Studio) with the Freescale SDK installed, along with the correct firmware on the FRDM-K64F Board. The goal is to drive Adafruit’s NeoPixel (WS2812B) with the Freescale FRDM-K64F board:
The Teensy is a great and tiny board (see “USB CDC with the Teensy 3.1 Board“), but it lacks real SWD/JTAG debugging capabilities (see “Hacking the Teensy V3.1 for SWD Debugging“). The Freescale Freedom boards are great, but for many applications too big, and have potentially too many components on it. So what about building a breadboard friendly tiny board which *has* SWD debugging ability *and* can be used to debug another boards?
So here is a working prototype based on the FRDM-K20D50M:
OpenOCD is an open source and free-of-charge debugging solution, which is a great option here at the University of Lucerne, as students do not need to buy an expensive debugging probe. Still, I recommend to buy professional probes like the P&E or Segger ones, as they are worth every (Euro) cent. But for a ‘zero’ budget, OpenOCD with CMSIS-DAP is something to consider. And with Kinetis Design Studio using the GNU ARM Eclipse Plugins, OpenOCD is not that hard to be used. And because both Freescale and GNU ARM Eclipse offer OpenOCD Windows binaries, that connection method is in the reach of Windows users too.
The Freescale FRDM-K64F and FRDM-K22F have a different OpenSDA (v2) firmware on it: unlike the earlier (v1), that firmware is open and not protected which is a great thing. However, it has the disadvantage if you use the wrong SWD/JTAG header on your board, the bootloader on the K20 OpenSDA microcontroller is gone 😦
I think the biggest frustration point for any new or even seasoned engineer is the debugging phase: my application finally builds fine, but I’m not able to connect and download it to the target board :-(. In my view the debugging part is the most fragile part of the development process. I’m always very relieved if I can connect to a brand new board, because I know if it does not work, then the problem could be a very bad one, costing my several hours or even days to overcome it.
I have received a bunch of Freescale FRDM boards to be used in an Embedded Systems programming crash course. There are multiple issues with the boards coming from the factory:
- They come with an old bootloader which is not compatible with Windows 8.x
- They have an old and outdated firmware on the board only supports a MSD bootloader
This post is a step-by-step instruction how to update Freescale FRDM boards (e.g. FRDM-KL25Z) to the latest firmware.