Vulnerabilities Discovered in FreeRTOS TCP/IP Stack 😮

A researcher has discovered multiple flaws in the FreeRTOS TCP/IP stack: Amazon/FreeRTOS quickly patched the problems, but that’s not the end of the story.

As more and more “Internet of Things” devices come onto the market, the existence of exploitable flaws will become unavoidable. As the provider of a (forthcoming) TCP/IP+RTOS stack in ImageCraft’s JumpStart IOT Suite, it behooves us to come up with a plan for if and when this happens. Clearly, we need to:

Continue reading
Posted in embedded market, news | Tagged , | Leave a comment

Dynamic Memory and REXIS

According to some coding guidelines such as MISRA, it is “common wisdom” that embedded firmware should not use dynamic memory, e.g. malloc/free, as it introduces non-deterministic behaviors. Many firmware engineers have taken this to heart. 

So is it surprising that REXIS (our forthcoming RTOS) uses dynamic memory allocation? Have we gone mad? Surely not ;-). REXIS uses dynamic memory for three main reasons:

Continue reading
Posted in new product | Tagged , , , , | Leave a comment

Interrupt Handlers and Tasks in REXIS

REXIS is both ImageCraft’s RTOS and a component of the JumpStart IoT Connectivity Suite. It’s easy to use and also supports multiple APIs for IPC (Inter-Process Communication). In this post, we aim to show how easy it is to write an interrupt handler to interact with a normal REXIS task.

Problem Description: in an embedded system, the most efficient method of detecting sensor and other data input is through peripheral interrupts. An interrupt handler, or Interrupt Service Routine (ISR), is called when the hardware device receives data (e.g.: a character arrives at a UART receive register). The ISR reads the data from the hardware device, and the data can then be processed by the firmware. Because interrupts preempt other code from running, to minimize performance impact on the rest of the system the ISR should do its job as quickly as possible and leave the more complex data processing to code that is not running in an interrupt context.

Why is this important? While the example in this post is trivial in nature (basically, it’s a terminal I/O echo program), it demonstrates one of the most important aspects of using an RTOS: use an ISR to handle a hardware event, and then pass the data to a normal task for data processing.

Continue reading
Posted in Uncategorized | Leave a comment

JumpStart C++ for Cortex Semihosting

JumpStart C++ for Cortex’s built-in debugger now supports semihosting. Your firmware can now use printf calls for diagnostic output without tying up a serial port.

Posted in new product | Tagged | Leave a comment

Firmware Security

Most modern MCU have some kind of readout protection of the flash. Unfortunately, there’s only the minimal level of protection of your firmware IP. The TL;DR version is that serious crackers can etch the physical shielding off, and then read the flash content via microscope.

There are also exploits that crackers can use. Here’s a case study of how the STM32F0 MCU can be cracked via exploits

What to do? Understand the risks and act accordingly. There is no one right answer, but there is a right answer for your situation.

Posted in Uncategorized | Leave a comment Reviews Our Book “C for Everyone”

Check it out!

Posted in Uncategorized | Leave a comment

JumpStart C++ for Cortex 9.05.00 Released

We now support semihosting!
direct download link:

9.05.00 2018/10/04
– IDE and JDB Debugger
Added Semihosting support. This redirects printf calls when
the program is under debugger control to the ADT’s
semihosting output window. See help file for detail.
Enabled support for USB licensing dongle. Once the driver
is installed, the IDE will recognize the dongle license
automatically whenever it is plugged in.

NOTE: Win8/Win10 users may need to install the driver
using the “unsigned driver install hack” (do a web search).

Posted in Uncategorized | Leave a comment

Repost of “Embedded Market Survey on RTOS Uses”

The following was written in April 2018 at the “other” blog platform. This has some relevance as we will be officially releasing “JumpStart IoT” which includes REIXS, our preemptive multi-priority RTOS.


If one examines the 2017 Embedded Market Study Survey: (…rket-study.pdf), the use of RTOS vs. no RTOS (page 54) has maintained a fairly consistent 70% (RTOS) to 30% (no RTOS) split for the last 5 years (and probably earlier as well). During the same time frame, the use of open source RTOS increased from 30% to 40%, while the use of commercial RTOS dropped from 40% to 30%.

Continue reading
Posted in embedded market | Tagged , , | Leave a comment

Everything Old is New Again

A few years ago, we updated our website with a modern CMS based system. It’s been working great, allowing us to add new products and other content easily. At the same time, we also tried different blogging and user communication platforms.

Based on what we learned, we are blogging again using WordPress at and restarting mailing lists, but now using a current platform from As we start this migration, you might get multiple invite messages. Apology in advance for any duplication.

All the old yahoogroups data, including files and messages, will be available! ( is founded by the same person that wrote the original yahoogroups mailing list software) You can access messages using the web and or email interface, use hashtags, etc. with lots of customization possible. The invite message will contain the different email addresses to use for sending messages, administrative commands etc.

See for the complete listing.

Posted in Uncategorized | Leave a comment

Little Things That Make A Big Difference

By embracing GCC in JumpStart C++ for Cortex, we have gained access to all the open source stacks such as TCP/IP, USB etc. that are incredibly valuable to customers writing complex firmware. On the other hand, we have lost something in the exchange. Primarily, GCC is NOT the world’s most user friendly piece of software.

For example, users of our home-grown V8 JumpStart C for Cortex-M are used to helpful feedback, such as seeing this message at the end of a Build:ROM 4% full. 17588 out of 524288 bytes used (does not include absolute areas).

RAM 2028 bytes used (does not include stack usage).
NOTE: Output file ".\Uart-test.bin" start address: 0x8000000

At a glance, this tells you how much memory is being used, and how much is left. This information is very important in both the prototyping stage, where the developers can use it to select the MCU with the most appropriate memory size, but also in the development stage, to ensure that the firmware will fit in the selected MCU. Unfortunately, this information is not readily available from a GCC compile.

Losing this sort of feedback would be a step backward, if not remedied. Therefore, in the 9.04.00 release, we have added a simple utility and post-command to generate something like this:

ELF file output size
Code size: 102468 bytes starting at 0x080001D0
SRAM data: 28016 bytes starting at 0x20000000
Heap and Stack: 5120 bytes heap starts 0x20006D70 stack starts 0x20008170

(Point of clarification: the two examples above are not from the same source files, so the memory uses are clearly different.)

The information is displayed differently with the GCC-based version, and currently we do not have the percentage-used available, but we expect to add those enhancements in future releases. On the other hand, this contains information that was not available under the previous compiler so indeed it is already even more useful.

This may seem like just a little thing, but it is very valuable in embedded firmware development. As we embrace open source software, we are committed to making it easier to use and more friendly in its operation. This is just one of the first steps.

Posted in Uncategorized | Leave a comment