Space is a hostile environment. Sending hardware to space means putting it under irradiation tests: exposing the object to radiation and see what happens :-). For this, under the lead of the ETHZ (Mathematical and Physical Geodesy), we had the opportunity to put the CubETH payload board under a proton beam. The test facility is at the Paul Scherrer Institute (PSI) in Villigen, Switzerland:
An interesting trend in the industry are SOM (System on Module): a high performance processor typically running Linux, Windows or Android with all the memory and necessary power logic gets put on a small module. The key benefit is that I don’t need to worry about the complex ball grid routing and the DDR memory connections/lines: all these problems are solved on a small module which then I can use in my design. It seems that NXP i.MX application processors are getting popular in this domain, and after looking at the Toradex Colibri modules, I have an i.MX6 module on my desk from e-con Systems:
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.
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! 🙂
In “ARM Cortex-M, Interrupts and FreeRTOS: Part 1” I started with the ARM Cortex-M interrupt system. Because the ARM implementation cann be very confusing, I confused myself and had to fix and extend the description in Part 1 :-). Thank for all the feedback and comments!
Originally I wanted to cover FreeRTOS in Part 2. Based on the questions and discussions in Part 1 I thought it might be a good idea to provide visual examples.
The ARM Cortex-M microcontroller are insanely popular. And it features a flexible and powerful nested vectored interrupt controller (NVIC). But for many, including myself, the Cortex-M interrupt system can be counter-intuitive, complex, inconsistent and confusing, leading to many bugs and lots of frustration :-(.
Understanding the NVIC and the ARM Cortex-M interrupt system is essential for every embedded application, but even for if using an realtime operating system: if you mess up with interrupts, very bad things will happen….
We are using robots to teach advanced embedded system programming at the Lucerne University (see “Sumo Robot Competition“). Students can buy the kit, and we are running out of available hardware. Time to produce a new series of robots :-). It took us a while to get to the next revision of the Zumo Robot, but finally the first one has been produced and assembled, and I think it is looking good :-).
I’m using Processor Expert components for nearly every Freescale (now NXP) projects: for S08, S12, ColdFire, DSC and especially all the different NXP Kinetis devices. Not only because it makes software development fast and easy and allows re-use of software, but as well because Processor Expert has a good way to pack and distribute software components. Unfortunately Processor Expert is not any more included for the new Kinetis devices (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“). So I have looked into an alternative and hopefully vendor neutral way to build and distribute software packages using CMSIS-Pack.
The reset and signal line of a microcontroller is probably the most important signal to a microcontroller. And if things go wrong, then a first thing to check is the reset line. So having control over reset is an important aspect for embedded development. You would think that if you download a program to a microcontroller, the debug probe would put the device into reset at the start with a short pulse like this: