I am still gathering feedback, so please consider taking my quick survey. As a bonus, you will have access to all of the responses once you complete the survey.

Hardware, Boot Sequence, and Performance

I have recently made some major progress on designing and implementing the hardware and software system that powers Stratify Toolbox. This was no easy task. The Toolbox is powered by the STM32H750 microcontroller and Stratify OS. The STM32H750 is an ARM Cortex M7 with an L1 cache and up to a 480 MHz CPU, which is a major workhorse. Stratify OS is a microcontroller RTOS that I have spent the last decade building specifically for ARM cortex chips. Bringing it all together required quite a bit of system integration.

Core Hardware

The core computing system looks like this:

Stratify Toolbox Computing System

Getting this to work required building three images of Stratify OS, each of which runs in a different part of memory.

Boot Sequence

Stratify Toolbox Boot Sequence

The bootloader checks for:

• A hardware request to enter Recovery Mode (short a pin to ground while pushing the external reset) which can flash images over USB
• A software request to launch the Maintenance OS
• A valid Application OS in external flash (indicated by a proper SHA256 hash)

Recovery Mode

Recovery mode is the easiest to run. It just keeps going in internal flash. It gives access to /dev/drive0 which holds the other OS images and allows them to be updated.

Maintenance OS

To run the Maintenance OS, the bootloader copies the Maintenance OS from external flash to internal ram and allows execution to take over. The Maintenance OS can access the SD card’s FAT filesystem and can read from or write to the external flash. This allows it to copy a new version of the OS (including a new Maintenance OS) from the SD card to external flash.

Application OS

Finally, the Application OS was the biggest challenge. It executes in place, but the bootloader needs to find its critical code section and copy it from external flash to internal, tightly coupled memory. It must then pass execution on to the Application OS.

Performance

Just to make sure everything was humming along, I ran a Dhrystone benchmarking application with both the Application OS (external flash) and the Maintenance OS (internal RAM):

• Maintenance OS: 464 DMIPS
• Application OS: 522 DMIPS

The Application OS leverages the internal tightly coupled instruction memory which is probably why it got the boost.

Building on a Raspberry Pi

One last note for the Linux fans: I got all the tools to build and run on a Raspberry Pi using either the serial port driver or libusb.