Hello everyone, I am Pi Zi Heng, a serious tech enthusiast. Today, I will introduce you to Super Download Algorithm Development Notes (1) Execution on Different CM Cores.
This article continues from the previous one titled RT-UFL – A Super Download Algorithm Design Suitable for All i.MXRT Platforms, and the open-source project initiated by Pi Zi Heng has officially started. I mentioned that I would document all the difficulties and solutions during the RT-UFL project development and share the secrets behind the download algorithm design.
This is the first article in the development notes, and we will focus on the foundation of this project, which is how to ensure that a .FLM (which is essentially the final executable machine code) can run normally on all i.MXRT chips.
1. Differences in the i.MXRT Family from an Embedded Program Perspective
Since the super download algorithm needs to run on all i.MXRT models, we first need to understand how many models there are in the i.MXRT family, what the differences between these models are, and which differences are the main factors affecting the super download algorithm.
The table below lists all 9 models that have been released in the i.MXRT family (Note: Some models have more than one chip, but only differ in the number of internal peripherals):
Although there are many differences when examining the chips themselves, we can analyze them one by one based on the three fundamental elements of an embedded program (instructions, peripheral operations, and link space):
From the table, we can see that all i.MXRT chips are based on the ARM Cortex-M core, which is actually the most important foundation for the entire project. Their instruction sets are consistent. However, although they are all Cortex-M cores, there are three processor versions involved (M4, M7, M33), so the first thing to consider when designing the super download algorithm is the differences in processor versions.
From the perspective of peripherals, the super download algorithm code may involve operations on the chip’s internal Clock, IOMUXC (pin), FlexSPI (Flash controller), and other peripherals. These peripherals will have differences, but they are not significant; we can introduce different code handling branches for different i.MXRT models.
Finally, from the link space perspective, the super download algorithm needs to be loaded into internal RAM for execution. The sizes of these i.MXRT internal RAMs vary, and their addresses in the system mapping address space are also slightly different, but this is also not important. If you have read my previous article Serial NOR Flash Download Algorithm (Keil MDK Tool Edition), you should know that the download algorithm code is position-independent, meaning that its loading address does not need to be fixed (it can be specified by the accompanying XML file or IDE project settings), so the differences in RAM are also not significant.
2. Solving Instruction Differences Between Different Cortex-M Processor Versions
From the analysis in the previous section, we know that the most important issue to address for the super download algorithm to run across the entire i.MXRT series is handling the differences in instructions between different Cortex-M cores.
Before solving the instruction difference issue, there is an important point that I must clarify: the interrupt vector table sequences defined for different Cortex-M chips are not the same. The first 16 are system vectors, as specified by ARM, but the subsequent interrupt vectors are defined by the manufacturers. Under different chip models, the vector numbers allocated for the same type of peripheral may not be the same, so embedded programs running on heterogeneous dual cores need to handle the differences in the interrupt vector table. However, this is not a problem for the download algorithm because it is not a typical embedded program; it does not contain an interrupt vector table, which means that the download algorithm does not use interrupt response functions and cannot enable peripheral interrupts (due to position-independent linking).
Now, let’s address the instruction difference issue. According to official ARM documentation, there are 10 processors in the Cortex-M family (M0, M0+, M1, M3, M23, M4, M33, M35P, M7, M55), which belong to four architectural specifications (ARMv6-M, ARMv7-M, ARMv8-M, ARMv8.1-M), and the architecture is mainly related to the instruction set.
Next, let’s take a look at two Cortex-M instruction set relationship diagrams. From the diagrams, we can see that the Cortex-M0/M0+/M1 processors are based on the ARMv6-M architecture, which supports only 56 instructions (highlighted in blue), and all Cortex-M processors support this set of 56 instructions.
Do you see the point now? ARM has designed Cortex-M processors with downward compatibility and upward binary compatibility features to allow software developed for Cortex-M users to be reused. In simple terms, machine code compiled for lower version Cortex-M processors can be executed directly on higher version Cortex-M processors.
Therefore, to implement the super download algorithm on the entire i.MXRT series (M4, M7, M33), we only need to do one thing: select the Cortex-M0 processor in the source MDK project settings when compiling the algorithm file. Isn’t that super simple? If you have downloaded the CMSIS_5 package, you will find that the default processor for the download algorithm template project is ARMCM0, and this is not just a coincidence!
Thus, I have completed the introduction to the super download algorithm development notes (1) on execution across different CM cores. Where’s the applause~~~