基于ARM嵌入式系统的ISP设计
1 硬件连接
ISP方案的硬件连接如图1所示。RS232转接板用来将RS232电平转换为TTL电平,并通过ISP_EN引脚给ARM开发板提供信号,让其进入ISP状态。PC机上运行用VC语言编写的ISP.exe,该程序把需要烧录到F1ash里的.bin文件加密后发送到ARM开发板,同时把烧录的进度提示显示给用户。图1中的阴影部分具有固定的程序。
2 Flash烧录原理
2.1 存储器分配
STR730是意法半导体生产的基于ARM7TDMI的微控制器芯片,内置16 KB RAM(0xa0000000~Oxa0003fff)和256 KB Flash(Ox80000000~Ox8003ffff)。内置256 KB Flash的分配情况如图2所示。按照图2中存储器的分配编写Scatter文件,在生成可执行文件时链接器会根据Scatter文件的内容把相关代码段定位到特定的地址上。该例中,程序从Flash启动,且没有使用存储器重映射,因此中断向量必须定位到Flash的起始位置。
扇区O的内容需要事先通过JTAG口烧入,此后就可以利用扇区O中的烧录程序Programrher.o通过串口进行ISP。在整个ISP过程中扇区0的内容是保持不变的,这样就可以防止ISP过程中出现掉电之类的意外,导致初始化代码Startup或烧录程序Programmer受到损坏而无法再一次进行ISP。
无论对嵌入式产品添加新功能还是修改原有的软件BUG,涉及的都只是用户应用程序的改动,初始化代码Startup.s是无需改动的,所以扇区O的内容在ISP过程中可否保持不变,关键是能否使首次编译生成的Vector.0始终与以后多次编译的App.o相匹配。
需要特别指出的是,当用户应用程序发生改变时,实际的中断服务函数(一般是C语言函数)很可能发生了改变,或者是实际的中断服务函数的入口地址发生了改变,怎么通过固定不变的中断向量Vector.o找到变化的中断服务函数的入口呢?只要这个问题解决了,就可以使首次编译生成的Vector.o始终和以后多次编译的App.o相匹配,这是该方案可行性的关键所在。为解决这个问题,笔者在Flash的固定位置(0x80002000~0x800020ff)做了一个中断映射表,实际上里面存放的是一条条跳转指令。由于中断映射表INTMap.s和用户应用程序App.c是一同编译、链接的,里面的跳转指令当然可以准确找到实际的中断服务程序入口;而位于扇区O的中断向量Vector.s虽然不和用户应用程序一起编译,但中断向量里的跳转指令是绝对跳转到固定的中断映射表区域。这样通过2次跳转就可以准确找到中断服务程序的入口。
可以通过图3看出快中断的处理流程(其他的中断处理流程类似)。
2.2 ISP执行的步骤
笔者把起到烧录Flash作用的程序单独作为一个工程编译、链接,生成.bin文件;然后把.bin文件转化成一个unsigned char型的数组,并把该数组放在一个单独的文件Programmet.c中;最后利用Scatter文件把Programmer.o定位在固定的地址空间(0x80001000~Ox80001fff,如图2所示)。这样一来,就可以编写汇编程序,把烧录程序Pro—grammer.o拷贝到RAM中,并让PC指针跳转到RAM中执行烧录。由于STR730没有外部Flash,要烧录Flash程序必须在RAM中运行,所以拷贝Programmer.o到RAM中是必需的。以下代码摘取自Startup.s。
CMP r1,#1
烧录程序Programmet的软件流程如图4所示。
需要说明的是:
①擦除Flash并不是完全擦除,而是擦除扇区0之外的其他扇区;
②数据缓冲区有限,每次只接收指定大小的数据,这样接收和烧录就可以并行进行,提高了ISP的速度;
③为了提高软件的安全性,原始的.bin文件是经过加密的,在烧录前需要将原始数据解密。
结 语
本文阐述的这种通过串口ISP的方法已经在实际的开发生产过程中使用。实践证明,相比其他烧录Flash的方法有很多优势,比如成本低、硬件连接简单、操作方便、增强软件的安全性等。笔者使用的MCU是STR730,稍做改动也可以把这种ISP方法推广到其他ARM体系结构的MCU上去。
参考文献:
[1].RS232datasheethttp://www.dzsc.com/datas
- Linux嵌入式系统开发平台选型探讨(11-09)
- 基于ARM体系的嵌入式系统BSP的程序设计方案(04-11)
- 在Ubuntu上建立Arm Linux 开发环境(04-23)
- 达芬奇数字媒体片上系统的架构和Linux启动过程(06-02)
- SQLite嵌入式数据库系统的研究与实现(02-20)
- 革新2410D开发板试用手记(04-21)