bootloader tftp1.4的bug分析及思路

chw75

在lumit4510中，bootloader tftp1.1是运行正确的，而bootloader tftp1.4却运行不正常。
今天我做了一个实验，步骤如下：
1、分析bootloader tftp1.1的网络数据
（1）用sjf4510把bootloader tftp1.1写到nor flash中。
（2）然后开启sniffer抓包工具，设置其能接收tftp包。
（3）连接交叉网线，打开超级终端。
（4）在终端上输入ipcfg 192.168.0.5 (因为我的主机ip为192.168.0.3)
（5）load
（6）在主机上输入命令tftp -i 192.168.0.5 put image.ram
（7）这个程序运行完毕
（8）关闭sniffer，并保存抓包信息。
2、分析bootloader tftp1.4的网络数据
（1）用sjf4510把bootloader tftp1.1写到nor flash中。
（2）然后开启sniffer抓包工具，设置其能接收tftp包。
（3）连接交叉网线，打开超级终端。
（4）在终端上输入ipcfg 192.168.0.6
（5）load
（6）在主机上输入命令tftp -i 192.168.0.6 put image.ram
（7）这个程序运行完毕（出现timeout error)
（8）关闭sniffer，并保存抓包信息。
3、获取tftp1.1和tftp1.4的数据
（1）tfp1.1的tftp的包的个数为3054个，每个包大小为512字节，最后一个包大小为448个字节。
（2）tfp1.4的tftp的包的个数为959个，每个包大小为512字节。第960个包传输总是出错。
4、分析问题的思路
（1）通过对比，可知道tftp1.4在第960个包出错。
（2）960*512=0x78000。也就是lumit4510在接收0x78000个字节出错。
（3）接收image.ram的开始地址为 0x8000,即可能在0x8000+0x78000=0x80000时，传输地址与程序中的某个设置地址冲突。
（4）查看tftp1.4工程中的源代码，其中设置0x80000的有两处。
isr.h文件中#define MAC_RX_INT 0x80000
vector.s文件中 MOV Sp,#0x80000
（5）查看tftp1.1工程中的源代码，没有设置地址在0x80000。
5、结论
可能在上面两处出现地址冲突，请斑竹测试更正一下，是不是能解决这个问题。

chw75

6、修改方案：
（1）在vector.s文件中 修改以下代码为
        ;set up irq stack
        mov         r0, #0xd2               ; make irq mode with all irqs disabled
        msr         cpsr_cxsf, r0
        MOV sp, #0x270000     ;MOV sp, #0x70000
       
        ;set up svc stack
    mov        r0, #0xd3                ; make svc mode with all irqs disabled
        msr        cpsr_cxsf, r0                 
        MOV sp, #0x280000    ;MOV sp, #0x80000
（2）然后重新编译就可以了。
（3）结果运行成功，能够正常load image.ram了。

7、修改思路
（1）在lumit4510中，Nor Flash为2M,SDram为8M。
（2）image.ram通常不会大于2M，所以把sp从0x70000和0x80000修改为0x270000和0x280000在SDRAM就不会产生堆栈与程序地址的冲突了。而在Nor Flash中，由于会地址重绕，则0x270000和0x280000在Nor Flash的位置还是为0x70000和0x80000。

limingth

确实是这里的问题导致 tftp 传输会中间死掉， chw75 目前的状态简直是神了，   
我一鼓作气把 tftp 1.6.0 写出来了，是在原来改了一些代码的 1.5.0 基础上，修正了 1.4.0 这个 bug 的一个版本，大家可以下载试试！