Most host or desktop systems (say Linux, Mac or Windows) have a normal use case where you start the operating system say in the morning and shut it down in the evening, and then you leave the machine. Embedded Systems are different: they are not attended, and they are supposed to run ‘forever’. Not every embedded system needs to run an OS (or in that world: Real-Time Operating System or RTOS), but the same applies here: after the RTOS is started, it is not intended that it will shutdown and restart. To the extend that you won’t they support the ‘shutdown’ and ‘restart’ functionality at all. In case of gathering coverage information this would be really useful:
coverage information from FreeRTOS application
In the case of FreeRTOS: what if I really need to shutdown the RTOS and restart it again, as by default this is not supported. This is what this article is about …
One of the great things with the FreeRTOS operating system is that it comes with free performance analysis: It shows me how much time is spent in each task. Best of all: it shows it in a graphical way inside Eclipse too:
This is the third part about ARM Cortex-M and how the interrupts are used. In Part 1 I discussed the Cortex-M interrupt system and in Part 2 I showed nested interrupt examples. This part is about FreeRTOS and how it uses the Cortex-M interrupt system.
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 very popular. And it has a very flexible and powerful nested vectored interrupt controller (NVIC) on it. But for many, including myself, the Cortex-M interrupt system can be leading to many bugs and lots of frustration :-(.
ARM Cortex-M7: NXP KV58
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….
Stack overflows are a big problem: If I see a system crash, the first thing usually is I try to increase the stack size to see if the problem goes away. The GNU linker can check if my global variables fit into RAM. But it cannot know how much stack I need. So how cool would it be to have a way to find out how much stack I need?
Static Stack Usage Analysis with GNU
And indeed, this is possible with the GNU tools (e.g. I’m using it with the GNU ARM Embedded (launchpad) 4.8 and 4.9 compilers :-). But it seems that this ability is not widely known?
In “A Processor Expert Component to Help with Hard Faults” I’m using a C handler with some assembly code, created with Processor Expert, to help me with debugging hard faults on ARM Cortex-M. Inspired by a GNU gdb script here, I have now an alternative way. As this approach is using the GDB command line approach, it works both with an Eclipse GUI and with using GDB in command line mode only :-).
I have several applications where I store application specific information in the microcontroller FLASH memory (see “Configuration Data: Using the Internal FLASH instead of an external EEPROM“). I have run into issues recently with the Segger J-Link GDB server as by default it does *not* erase all the FLASH memory. So the question is: How can I erase all (or part) of the FLASH memory with GDB (e.g. in Kinetis Design Studio or in Eclipse)?
In my earlier post I used a hacked together shield for building a clock based on Adafruit’s NeoPixel/WS2812 (“LED Clock with Kitchen Hot Pan Protector“). The new design supports now 8 parallel data streams, integrated realtime clock and wireless connectivity with the nRF24L01+ module.
Newer microcontroller have increase RAM areas, making it suitable to run the application from RAM instead of FLASH. For the FRDM-K64F board and the Kinetis Design Studio (V1.1.1), I have explored how to run the application out of RAM instead of FLASH memory, both for P&E and Segger connections.
Many applications need to store persistent (non-volatile) data at runtime: configuration data, error logs, sensor data, calibration values, etc. The question is: where to store that data? If it is only a few kBytes, an SD card or similar is an overkill. Adding an external EEPROM? Sure, that works, but adds an extra part to the design. Some microcontroller have internal EEPROM. But what if not? Why not using the microprocessor internal flash memory?
In “IoT: FreeRTOS Down to the Micro Amps” I’m using an application with FreeRTOS to get down in micro amps low power mode. Well, nearly all or my applications are using FreeRTOS because it makes the application scalable and extensible. Still, for anyone not used to an RTOS, that might be a hard start. So here we go: how to get into the Kinetis Low Power LLS Mode *without* an RTOS.
I have created and published on GitHub a new component ‘CriticalSection’:
Critical Section Component Methods
This component is a wrapper between my components and the problematic current implementation in Processor Expert (see EnterCritical() and ExitCritical(): Why Things are Failing Badly). It uses a flexible approach and uses macros to either use my modified version of EnterCritical() and ExitCritical(), or simply defaults to the original implementation.
For my embedded systems lecture I need a wireless connection to the robot we will develop during that course. So far I have SMAC (IEEE802.15.4) and Bluetooth worked out. But that IEEE802.15.4 (ZigBee) is expensive, and the cheap Bluetooth modules are great for robot-to-host connection, but not for swarm robots which need to communicate to each other. Alex Vecchio (see this post) pointed me to a $2.75 (!) wireless module featuring the Nordic Semiconductor nRF24L01+. Exactly what I needed, with an incredible low price :-).
I’m working with a student on building a small autonomous robot platform, based on the FRDM-KL25Z board. We integrated new software modules, compiled and linked, and then downloaded the application to the board. While debugging and stepping through the application startup, I had this:
The Debugger has lost communication on connection
Outsch! That’s not good. Even worse, trying to connect again to the board failed :-(. What happened?