For a CubeSat project we only have a single board available. But multiple universities and developers need to have access to that board for developing and debugging the firmware. We cannot easily ship around the board: that takes a lot of time and during shipment nobody can use the board.
There is a nice feature in the Segger J-Link software which allows to share the debug connection over the network: the J-Link Remote Server. It even works nicely between different networks without complicated firewall setup:
The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
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:
Repgrogramming the Mikroelektronika Docking Station
Time is passing by so fast, and the year end is approache fast! I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge:
Percepio Trace V3.1 for FreeRTOS which includes both Segger RTT continuous streaming and snapshot tracing in a single API
Generation of sources and drivers so they can be used without Processor Expert using McuLibConfig, removal of dependency to NXP Kinetis SDK: components use a generic API approach to have them working with other SDKs.
New contributed ExceptionsHandler component
Callback Setter and Getter in USB CDC stack for simpler option handling
GenericTimeDate with flexible RTC support and added Unix Timestamp functions
LongKey events in Key component
FreeRTOS with optimized task selection on Cortex-M4/M7
The Hexiwear device is a great and versatile device with two microcontrollers on it. Developing firmware on a Hexiwear means changing what was originally on it. And sometimes it happens that I’m not sure if the changes are for good. Or that I accidentally destroyed the firmware on the NXP Kinetis KW40 BLE microcontroller :-(. So I had to find a way to restore the original firmware, and this is what this post is about.
Restoring the Hexiwear Firmware with a Segger J-Link
It seems to me that not many developers use hardware trace? ARM indicates that maybe only <5% of developers are using trace. Too bad! Why are all the ARM Cortex microcontroller vendors putting a powerful hardware (and complicated!) trace engine into their devices, if only few developers are using it? Seems like a waste of silicon and an unnecessary price adder? Well, hardware trace can be a life saver: Because only with hardware trace the most complicated bugs and problems can be solved. And maybe because only the best are using it ;-).
From time to time I face some problems which are really hard to find. Mostly these kind of bugs are very timing sensitive and depend on interrupt execution order. Maybe a dangling pointer is overwriting memory, code is running wild, or some functions are not reentrant as they should be. For these kind of bugs, good tools are worth their weight in gold. The Percepio FreeRTOS+Trace and the Segger SystemView have helped me many times to narrow down such kind problems in my applications. Another ultimate tools is hardware trace: Now I have a Segger J-Trace Pro for ARM Cortex-M in my arsenal of bug extinguishing weapons on my desk:
Dear bugs, look what I have on my desk. Your hiding time is over! 🙂
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:
I’m using the Segger SystemView in many of my applications to get insights of the running application. A reader of my blog pointed me to the company ‘toem’ (http://toem.de/) based in Germany which offers powerful data viewer (‘impulse’) for Eclipse. I have tried this out, and it is really an amazing piece of technology with lots of potential. It allows me to view Segger SystemView data 🙂
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.
FRDM-K64F (top) programming the OpenSDA Bootloader (bottom)
For a university research project I need a fast microcontroller with lots of RAM and FLASH memory. I have ordered a TWR-KV58F220M board from NXP which arrived yesterday. The special thing is that it has on of these new ARM Cortex-M7F on it:
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: