For a research project, we are going to send a satellite with an embedded ARM Cortex microcontroller into space early next year. Naturally, it has to work the first time. As part of all the ESA paperwork, we have to prove that we tested the hardware and software thoroughly. One pice of the that is to collect and give test coverage evidence. And there is no need for expensive tools: Free-of-charge Eclipse and GNU tools can do the job for a space mission 🙂
Eclipse for C/C++ (CDT) offers two different ways to get out of a debug session: Terminate and Disconnect:
The terminate and disconnect behaviour is not standardized, and varies between Eclipse distributions and debug connection. This article is about how things are handled in MCUXpresso IDE, and how I can influence the behaviour.
I’m using Eclipse based IDE’s to develop and debug my embedded applications. This works great, as Eclipse has all the necessary tools to edit, build and debug it. But when it comes just to download/flash a binary to the board, then things are pretty much specific to the tools used. With the advent of the new MCUXpresso IDE, here is how that Eclipse IDE can be used for this.
Looking for a small, inexpensive ($25-30) ARM development board (say 120-180 MHz ARM Cortex-M4 with FPU, 512kB-1MB of FLASH and 256 KByte of RAM? Then have a look at the Teensy 3.5 and Teensy 3.6 by PJRC/Paul Stoffregen:
The only problem? it is not possible to debug it :-(. At least not in the traditional sense. This article is about how to change the board to use it with any normal SWD debugging tool e.g. Eclipse and the Segger J-Link :-).
There are many mergers going on in the industry, and one of the largest one was in 2016 the integration of Freescale Semiconductor with NXP Semiconductors, with both providing Eclipse based IDE’s to their customer base. Consequently, the company merger triggered a merger of the IDE’s, and last week NXP has released the result: the MCUXpresso IDE.
This year I managed to attend the Embedded World in Nürnberg/Germany after missing the 2016 show. And 2017 has been a blast! With more than 1000 exhibitors and >30’000 visitors it was huge! There were too many exciting things, so I just pick a few: NXP demonstrated the new MCUXpresso Software and Tools with a new Eclipse Neon based IDE, lots of IoT and Hexiwear, the tiny LPC800-DIP board, and I have met Alan Hawse in person!
With debugging FreeRTOS applications in Eclipse, it is a big to have views available showing all the threads, queues, timers and heap memory allocation. One of the best Eclipse plugins are the one NXP provides for FreeRTOS: they are free of charge and give me pretty much everything I need. However, if you are not that familiar with FreeRTOS itself, here are a few tips to get more out of the plugins.
Questions from students or readers of my articles are a great source for all kind of articles. And here is the ‘question of this week’: “What is realtime debugging”?
It’s a good question because the topic of ‘realtime’ and ‘debugging’ was a topic in the lectures this week. So this question gives me the opportunity to combine the two things of ‘realtime’ and ‘debugging’, I love it :-).
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:
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following main features and changes:
- New Sharp Memory Display Driver supporting 96×96 and 128×128 pixel ultra low power display
- PID_Int can be used without hardware
- GenericTimeData has added functions to convert date/time into strings
- HardFault can now disable write buffers on ARM Cortex to simplify debugging faults
- Folder support for SEGGER SystemView and Percepio FreeRTOS+Trace
- Component usage without Processor Expert
- NXP MCUXpresso SDK support for FreeRTOS using tickless idle mode and low power timer
- Many other smaller bug fixes and enhancements
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.
On the other side, the ‘middle and lower end’ Embedded world is fragmented and in many aspects proprietary. So it was no surprise to me when the Linux Foundation announced the ‘Zephyr’ project back in February 2016:
“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:
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
- Many smaller bug fixes and enhancements
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.
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 ;-).
Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
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:
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! 🙂