ARM Cortex-M3权威指南：第二版开发宝典

需积分: 6 157 浏览量更新于2024-07-18 收藏 14.83MB PDF 举报

"《ARM Cortex-M3 权威指南 2nd Edition》是关于ARM Cortex-M3处理器的详细开发手册，对于深入理解Cortex-M3的架构和开发工作至关重要。这本书由Joseph Yiu撰写，由Elsevier出版社出版，提供全球多地的发行版本。" ARM Cortex-M3是ARM公司设计的一种高效能、低功耗的微控制器核心，广泛应用于嵌入式系统设计。此权威指南的第二版更新了相关信息，并深入解析了Cortex-M3的核心特性、指令集、内存模型、中断处理机制以及系统级集成等关键知识点。 1. **Cortex-M3架构**：Cortex-M3基于Thumb-2指令集，优化了代码密度，同时保持了高性能。它采用三级流水线和哈佛结构，支持单周期乘法和硬件除法。Cortex-M3内核还包括了一个浮点运算单元（FPU），虽然不是标准配置，但可选配以支持浮点运算。 2. **中断处理**：Cortex-M3有一个高效的中断管理系统，能够快速响应中断请求，这对于实时系统至关重要。它支持抢占式和非抢占式中断，中断优先级管理灵活，能够满足不同应用需求。 3. **存储器系统**：Cortex-M3支持多种内存类型，包括Flash、SRAM和其他类型，具有独立的数据和指令总线，以及内存保护单元（MPU）以确保数据安全。 4. **调试功能**：内置的调试接口如JTAG和SWD（Serial Wire Debug）使得开发者可以在系统运行时进行调试，提供了丰富的调试工具支持。 5. **开发工具和生态系统**：Cortex-M3拥有广泛的开发工具链支持，包括编译器、模拟器、调试器等，以及众多的第三方开发板和软件库，为开发者提供了便利的开发环境。 6. **应用实例**：本书可能会涵盖Cortex-M3在物联网设备、汽车电子、工业控制、消费电子产品等多个领域的实际应用案例。通过阅读这本权威指南，读者可以掌握Cortex-M3处理器的设计原理，学会如何有效地利用其特性进行嵌入式系统设计，从而提高产品的性能和效率。书中还可能包含详细的编程实例和故障排查技巧，帮助开发者解决实际开发过程中的问题。对于想要深入理解和应用Cortex-M3的人来说，这是一本不可或缺的参考书籍。

Contents

APPENDIX E Cortex-M3 Troubleshooting Guide ................................................................ 421

E.1 Overview ................................................................................................................421

E.2 Developing Fault Handlers ....................................................................................422

E.2.1 Report Fault Status Registers........................................................................423

E.2.2 Report Stacked PC and Other Stacked Registers .........................................423

E.2.3 Read Fault Address Register .........................................................................425

E.2.4 Clear Fault Status Bits ..................................................................................425

E.2.5 Others ............................................................................................................426

E.3 Understanding the Cause of the Fault ....................................................................426

E.4 Other Possible Problems ........................................................................................429

APPENDIX F Example Linker Script for CodeSourcery G++ ............................................... 433

F.1 Example Linker Script for Cortex-M3 ...................................................................433

APPENDIX G CMSIS Core Access Functions Reference ..................................................... 439

G.1 Exception and Interrupt Numbers ..........................................................................439

G.2 NVIC Access Functions .........................................................................................440

G.3 System and SYSTICK Functions ...........................................................................443

G.4 Core Registers Access Functions ...........................................................................443

G.5 CMSIS Intrinsic Functions .....................................................................................444

G.6 Debug Message Output Function ...........................................................................445

APPENDIX H Connectors for Debug and Tracers ............................................................... 447

H.1 Overview ................................................................................................................447

H.2 The 20-Pin Cortex Debug + ETM Connector ........................................................447

H.3 The 10-Pin Cortex Debug Connector .....................................................................449

H.4 Legacy 20-Pin IDC Connector ...............................................................................449

H.5 Legacy 38-Pin Mictor Connector ...........................................................................449

APPENDIX I Access Your Embedded Controller with Ease through a Web Server ............... 451

I.1 The Human-Machine Interface ..............................................................................451

I.2 Web Server .............................................................................................................452

I.2.1 Source of Content ..........................................................................................453

I.3 Cost-Effective Networked Embedded Control—Stellaris .....................................454

I.4 Summary ................................................................................................................459

APPENDIX J Stellaris

Family of Microcontrollers ............................................................ 461

REFERENCES ..................................................................................................................... 497

INDEX ................................................................................................................................ 499

xvii

Foreword

When I rst approached ARM management to propose a new MCU architecture in 2003, I did not

know what kind of response I would get. I carefully explained the MCU landscape in terms of the wide

array of incompatible 8-bit, 16-bit, and 32-bit parts. My point was that the world was crying out for a

standard architecture to make things easier for the developer, but that the ARM7/ARM9 was not in that

lineage. Of course many people at ARM had previously suggested an MCU strategy, but my perspec-

tive was that you had to learn from the successes (and failures) of the real workhorse MCUs, not just

the ARM history, which was based on desktop computers. Since I had developed code for many of the

8-bit and 16-bit parts from 8051 and 8080/Z80 to PIC to MSP430 and ARM7, I had the battle scars

needed to understand what worked and what did not.

Internally we called this new architecture “Thumbnail”, since the intent was to build it from Thumb

and the new Thumb-2 extensions we were designing. We decided that it had to be focused on both

general purpose MCU and Automotive. The basic architectural design was rened through discussions

with ARM partners, automotive developers, and potential users of this new processor. Some features

that may seem odd to the general purpose developer were put there specically for the automotive

world and in particular AUTOSAR; these extensions turned out to be fortuitous for the general devel-

oper because of the increased focus on functional safety and security.

From the beginning, I was determined to make this an interrupt processor, much as a 68K or 8051

was. Although that would be quite contrary to the ARM tradition, interrupt processing is often what

deeply embedded applications are all about. By determining that interrupt processing would be in the

DNA of the architecture and processor, it meant extending past the normal ARM denition of a core

processor to including a proper interrupt controller. Having the interrupt controller integrated into the

processor meant that we could change the very nature of what the processor could do. Although I

looked at the usual “shadow registers” model employed by various processors to handle nesting, there

are always developers who need just one more set to meet their needs, and the cost of saving/restoring

is too painful to contemplate. So, the logical conclusion was to have the processor save the registers

on the stack in hardware. From that, we were able to develop a number of patented techniques that

not only made it faster and smaller, but also ensured standard compiled languages could just work

normally and naturally. Equally, we built an RTOS kernel concept right into the architecture to ensure

the smoothest use of an RTOS if wanted, or to comfortably skip one if not. Finally, I was determined

to end the “debug as afterthought” approach I had suffered with so many times in the past. Every effort

was made to provide Champagne debug support on a Beer transistor budget; this included plenty of

breakpoints on code in ash, powerful watch-points, meta-trace that could be handled by very low cost

hardware probes, and access to the system while it was running. Every aspect of debug support was

oriented to the needs of the developer and what was likely to be supported by the tools they buy—if it

won’t be supported, why bother adding it?

To grow from an architecture to an actual processor is not an easy birthing. After a few false starts,

a couple of us started a skunk-works project we called “TazCat”. We named it that because at the time

we were using types of cats for project names at ARM, and TazCat was based on the Tazmanian Tiger,

which was thought extinct but continues to have sightings. TazCat became an ofcial project at the

end of 2004 and was renamed SandCat. Thumbnail was renamed ARMv7-M (M for MCU) as part

of a new architectural naming—we could not very well call a cut-down architecture ARMv8, as the

xviii

Foreword

larger number is supposed to mean yet more features. Similarly, the Cortex processor naming was used

because an ARM13 processor could not be tiny compared to an ARM12.

Cortex-M3 was developed with a very heavy focus on gate count, power use, dynamic speed range,

and efciency. Gate count was a major consideration only because it affects power and efciency and

is usually a good metric for whether you did it well vs. brute force. Signicant focus was put on power

because the MSP430 had shown the value of very low power consumption in broad MCU applications.

Yet, at the same time, a lot of focus was put on maximum clock speed. One of the major issues with

most existing MCU processors is that they are very limited in top speed. Although many applications

may be ne at 10 or 20MHz, many applications need more. Further, many existing applications will

need to do more or do it faster over time, so top speed cannot be capped. That said, MCUs run from

ash memory, and ash becomes the major limiting factor in process geometry choice and top speed.

So, extra effort was made to allow Cortex-M3 to run efciently even when the ash was slower than

the core speed.

Cortex-M3 was co-developed between our small group in Walnut Creek, California, and a team in

Cambridge, UK. We had verication and validation engineers in India. This was not only a truly global

endeavor, but the sun never set on the development team! We used that time difference to maximize our

development and were able to come in under budget and on schedule. We also used additional testing

and validation techniques to ensure highest quality: we ran real applications from day 1. By working

with the compiler team from the outset and by compiling real-world applications (and not just vectors

and benchmark suites), we could nd bugs that only real developers would see. Our demonstration sys-

tem running on a regular speed/size FPGA included running the DivX decoder showing 15fps video on

a VGA screen, MP3 and WMA encode and decode in realtime, GPS decode from raw data, Doom (the

game), spinning a brushless DC fan motor (with speed control input and output via serial), and many

applications sent to us by various developers in automotive and industrial companies; of course we also

ran all of the normal benchmarks from Dhrystone to EEMBC. What is important is that this technique

also allowed us to tune timing on instructions to optimize real code generated by real compilers.

Part of the original concept proposed to the ARM management and board was that we needed a

real lead partner in the general purpose market. The new architecture would have to be evangelized

and we could not wait 2 years for the 1st Silicon as was usual for ARM’s partners. Further, we wanted

a company that was not trying to protect their own proprietary processor. Coincidentally, Jean Anne

Booth of newly-formed Luminary Micro approached ARM about doing an MCU. It was a perfect t,

and Luminary Micro quickly became the 1st lead partner for Cortex-M3. Luminary was exactly what

we were looking for—a strong management team with broad experience in the embedded space and

the know-how to set up worldwide distribution. Further, Luminary put together a strong engineering

team with signicant ARM experience, so we did not have to worry about them not understanding how

to work with an AHB-Lite bus. Our 2nd lead partner was Texas Instruments’ automotive group, so we

had covered the two main objectives perfectly.

When we shipped our early access release (the 1st production version of the processor) in early

2006, Luminary taped it out 2 weeks later! This was unheard of in the industry and a real testament to

their IC engineering team as well as to the close relationship between ARM and Luminary. Further,

they were willing to do this because we in the SandCat team had convinced them that it was bug free;

being a startup, Luminary could not afford to fabricate a buggy and therefore worthless chip. The other

lead partners took much longer to have 1st parts, as was typical. By Luminary having a chip right away,

ARM was able to show the world Cortex-M3 as a real product and not just slides or an FPGA demo

xix

Foreword

board. Further, by Luminary pricing the 1st chip at $1 (US), it broke all notions of the price barriers

between 8-bit and 32-bit processors. Cortex-M3 was off and running.

One of the real strengths of Luminary Micro from the beginning was that they understood the

importance of tools and software to MCU developers. Luminary raised the standard by a wide margin

from the very beginning: from low cost evaluation boards and easy out of box experience to a wide

variety of examples, developers were able to get started quickly and easily—a tradition still found

today with Texas Instruments’ Stellaris Cortex-M3 products.

I think the 5 truly innovative approaches to the MCU world that Luminary used (and many have

tried to copy) were: low cost evaluation boards that had their own USB debug HW probe built in, being

able to use the same low cost evaluation boards as debug probes for the customer’s own board, hav-

ing broad and interesting examples that worked with multiple tools, providing a standard open driver

package (called DriverLib then, now more broadly called StellarisWare) that meant you did not have

to read the datasheet, and having powerful reference designs that were available in source form. Nor-

mally, MCU vendors have a few examples that blink some LEDs and print “hello world” on a serial

port; after that, they rely on customers and FAEs and a lot of time to get a hodgepodge of examples

and demos that often do not work on newer parts nor with different tools. Luminary took the approach

of very sophisticated examples that allowed developers to start from real code and extend from there.

They had reference designs that were more real-world, such as the autonomous robot car, the CNC

milling machine, and the like; each demonstrating real-world embedded system techniques. Further,

they not only understood the importance of RTOS and tools support, they made sure that all examples

worked with all tools and all OS-oriented examples worked with all RTOSes. This coupled with a well

thought-out standard software library (drivers for peripherals, startup code, protocol stacks, etc) meant

that developers could be productive in minutes. That approach has helped to launch Cortex-M3 into

many applications around the world.

Since I believed that Luminary Micro was already bringing innovation to the general developers, it

should come as no surprise to you that when I left ARM in 2007, I joined Luminary to help drive further

adoption of Cortex-M3. Luminary Micro was acquired by Texas Instruments in May 2009, and is now

the Stellaris Business Unit, still doing everything Luminary was doing and more.

With that background, know that you will be using a processor and tools and system all designed

to make your job easier, more enjoyable, and more effective. There will no doubt be many features of

Cortex-M3 you never use, but they are there for the day when you nd you need them.

—Paul Kimelman

剩余530页未读，继续阅读

zhugeqingmei

粉丝: 0
资源: 3

ARM Cortex-M3权威指南：第二版开发宝典

m3forth 是用于 cortex-m3 ARM微控制器的第四个交叉编译器_Forth_代码_相关文件_下载

Fluke 8050A 万用表 LCD TFT 显示转换，带有基于 Forth 的STM32F103微控制器

arm cortex-m3与cortex-m4权威指南 pdf

arm cortex-m3与cortex-m4权威指南英文原版叫什么

arm cortex-m3与cortex-m4权威指南

arm cortex-m3 与 cortex-m4 权威指南(第三 版) pdf

arm cortex-m3与cortex-m4权威指南电子版

《arm cortex-m3 与 cortex-m4 权威指南(第三版)

《arm cortex-m3 与 cortex-m4 权威指南(第三版)》, joseph yiu 著,吴常玉、曹孟p

arm cortex-m3和cortex-m4处理器权威指南

最新资源

arm cortex-m3 与 cortex-m4 权威指南(第三版) pdf