本帖最后由 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供电，电池则处于充电状态，所以跟电池电量无关系。 |
|
楼主
谢谢分享。
