Migrating ARM7 code to a Cortex-M3 MCU

Todd Hixon

October 30, 2009

Todd Hixon

The ARM Cortex-M3 core has enhancements to its architecture that result in increased code execution speed, lower power consumption, and easier software development (Table 1). The result is a true real-time core that overcomes real-time processing limitations of the ARM7TMI core. Over time, most ARM7-based designs will be migrated to the Cortex-M3.

View the full-size image

Although ARM has done a lot to make it easy to port legacy code from the ARM7 to the Cortex-M3 core, more remains to be done. The purpose of this two-part article is to take you step-by-step through the porting process, so you will have no excuses when your boss asks to you to port some legacy code and have it ready by last Wednesday.

One of the most helpful things ARM has done is to make sure that Cortex-M3 support has been added to every ARM tool chain, which makes code compilation a straightforward process that can be done in just a few days in most situations. In fact, the most important consideration when migrating a legacy ARM7 design to the Cortex-M3 is selecting a device with peripheral hardware that is identical to that on the ARM7 in the current design. If the programming interface is different, new peripheral drivers will be required. This effort could add days or weeks to the schedule (never a good thing).

Using an M3 with identical peripheral hardware enables the software engineer to reuse most (if not all) of his C language driver code, saving days or even weeks of learning the nuances of new peripherals often associated with developing a robust driver from point zero. Vendor-supplied header files handle any relocation of peripheral register addresses--the developer simply includes the file for the Cortex-M3 device and recompiles the code.

There are, however, several differences between the Cortex-M3 and the ARM7TDMI that engineers must address (shown in Table 2) in their designs. Initially in this article, I'll explore the issues that arise in dealing with exception vector table formating, startup code/stack configuration, RAM functions remapping, and hardware interrupt configuration. Part 2, available online at Embedded.com, will address software interrupts, fault handling, the SWP (setwatchprops) command, instruction time, assembly language, and optimizations.