本帖最后由 nicholasldf 于 2011-12-29 10:31 编辑
这是这段时间搞STM32做的一个引导程序。官方有一个基于USART+ymodem的引导程序,但不满足需求,所以才写了自己的引导程序。
下面是该引导程序的来历说明:
1、以前在搞at91sam9260时,做了一个USART+zmodem的引导程序,就是上电时,尝试zmodem连接,如果连接不上,就从DATAFLASH读取应用程序并运行,如果检测到PC机超级终端有zmodem发送行为,则通过超级终端的zmodem的发送功能,把程序发到引导程序,引导程序再写入到AT45DB161 DATAFLASH存储器。这样就非常方便,再也不用通过SAMBA烧录,也不要拔开关。由于9260内部只有4KRAM,所以引导程序不能超过4K,把zmodem裁减到只有接收的功能,并且去掉CRC32的校验,因为CRC32有一个校验表格很占空间,,只保留CRC16校验。优化等级调到最高,这样勉强下来,做到了4K大小。发送512K的程序,用时大概1分钟。
2、在9260应用层,我采用的是全功能的zmodem程序,有接收、发送、CRC32校验功能。同时,把USART+zmodem改成USB虚拟串口+zmodem,发现测试速度大大提升,发送512K程序,只用了几秒钟。
3、基于上述经验,移植了ST官方的USB虚拟串口,只要USB接收和发送部分,不要USART部分。同时加上LCD显示、DATAFLASH驱动、FLASH擦除和写入、蜂鸣器、按键,可以升级STM32应用程序、其他要烧录固化的资源,,存储位置可以是STM32的FLASH、Dataflash等等。
STM32BootLoader开发说明
1、移植了360-APP的zmodem文件传输协议,支持32位CRC校验加快传输速度;也移植过360-BOOT的zmodem但发现传输速度很慢;
2、移植USB虚拟串口,参照360-APP,加上流控制;
3、移植ST官方的基于USART1+ymodem的引导程序,抽取有用部分,如跳转、FLASH清除写保护、FLASH擦除、FLASH编程;
4、引导程序占用32K,占用0x08000000-0x08008000,应用程序大小480K,如果烧录程序时越过边界,会产生不可预料影响,
如引导程序被破坏,应用程序不能正常启动,基于此,引导程序加入了烧录程序大小检查,超过指定大小时,中止会话提示
并烧录失败;此外,解决移植过程中的编译错误,如STM32BootLoader文件夹的包含路径设置为..\.\STM32BootLoader(放在
非中文路径都可以)或e:\STM32BootLoader(只能放在E盘根目录),解决外设库与MDK自带外设库冲突的编译报错;
5、移植uCGUI的6x8和8x8英文字库,加入LCD驱动,背光用IO口直接驱动,并实现LCD显示字符串函数;
6、移植蜂鸣器功能,M25P16驱动,基于SysTick的精确的延时函数;
7、异常程序中,加入关机程序,防止陷入异常导致无法关机;
8、开机按住OK键2秒则认为是正常开机,同时按住left键进入引导程序;进入引导程序后按住right键关机;
9、程序采用最高等级优化,缩小代码空间,更重要的是最高优化等级能提高程序执行速度;
10、应用程序烧录到0x8008000开始处,应用程序编译空间为0x08008000-0x08080000,大小0x78000,480K;
11、引导程序大小为0x4000时,测试OK,定义为0x5000时,测试失败,烧录应用程序后,引导程序也无法运行,估计跟STM32内
部FLASH分区有关系,烧录应用程序时,将引导程序的最末端部分程序擦除了,最后定义为0x8000,稍有点浪费FLASH空间,未
测试0x6000,ST官方的基于USART1+ymodem的引导程序大小为0x2000。
12、烧录注意:超级终端设置为115200、8位数据位、1位停止位、无奇偶校验位、无硬件流控制;用联想笔记本做测试,发现
用JLINK仿真器调试时,zmodem传输速度正常,烧录速度正常,但是不用JLINK仿真器调试时,zmodem速度很慢,数据包频繁出
错,烧录速度很慢,换成台式机USB接收,不用JLINK调试,一切正常。估计跟USB供电能力有关系,笔记本USB电源供电稍差,
台式机正常。插上USB后切换到USB供电,电池则处于充电状态,所以跟电池电量无关系。 |