关于DFU的一些问题和心得

hh312

首先感谢 八度空间 的帖子 http://www.openedv.com/posts/list/0/28532.htm，一开始什么都不会的时候，就是看这个帖子开始的。现在尘埃落定，在这个基础上，再谈谈自己的一些心得。
1、在APP程序的这句偏移中断向量的代码   SCB->VTOR = FLASH_BASE | 0X30000;  感觉也可以放在 boot 代码中。对于做练习的，这句代码放在哪里都无所谓，但是对于实际生产来说，这句代码放在APP，无疑增加了维护难度，对APP代码来说，就像眼里揉进了一粒沙子般让人不爽，所以我决定将其放到boot代码中（放在Jump_To_Application();这句前面），实际测试是没问题的，而且放到boot代码中时，这句可以这样写 SCB->VTOR = ApplicationAddress，简洁明了，ApplicationAddress 有变动时不需做任何修改。


2、八度空间 把官方代码中关于 SPI Flash 和 NOR Flash 部分的代码删除了，但是运行后，上位机程序中仍然显示出 SPI 和 NOR 的选项，对于追求完美的人来说，这两个项目显然很碍眼。而且这两个选项不是上位机来的，不需要研究上位机程序，所以很容易把它删除了，删除方法是：
（1）、找到 DFU_ConfigDescriptor[DFU_SIZ_CONFIG_DESC] 这个数组，把里面注释块 “Descriptor of DFU interface 0 Alternate setting 1” 和 “Descriptor of DFU interface 0 Alternate setting 2” 共18个元素删除，DFU_SIZ_CONFIG_DESC 这个元素个数定义相应改为 27.
（2）、找到 DFU_String_Descriptor[7] 这个数组，删除最后面两个元素，数组个数相应改为 5。
运行程序后，就会发现界面中间那个列表中只有internal flash 一行了。

3、特别说明一下（原帖也已经有人回复了），MAL_GetStatus这个函数的内容必须有的。没有这个函数，erase 和 write 速度超快，显然已经忽略了flash的读写延时了，所以基本是无法烧录成功的，只有极其短小的代码才能侥幸成功。这个事情因为八度空间老大没有写入那个PDF文件，我一开始又只保留了那个文件，论坛也没怎么来逛，折腾了好久，后来才隐约想起在哪里见过一句话，说如果代码较大时要注意什么，才自己把MAL_GetStatus这个函数补全的，然后才发现这句话原来就是八度空间自己说的，建议八度老大把这句话也写入PDF文件吧，或者例子中补全这个函数，小弟被你害苦了~


4、如果您不是使用eclipse写代码，这一段就不用看了。关于如何在eclipse中设置flash地址，也颇费一番心思，利用Jflash软件修改hex文件地址，不成功；利用bin文件再修改地址，也不成功。后来终于发现，按照网上提供的方案，在eclipse项目中，有个mem.ld文件，里面就可设置flash起始地址。还有要注意，设置后必须清理工程重新编译，否则如果其他文件没改动，再编译还是原来的hex文件的。这个东西网上很难找到资料，这里也顺带共享一个。


5、关于hex合并的问题，如果使用jLink，你的电脑里必定有jflash这个软件，这个软件就有合并hex文件的功能。这样，你就可以把boot代码和app代码合并成一个hex文件，一次性用仿真器烧录进去了。经测试是成功的。jFlash是很强大的，比如原子哥的光盘中提供的ISP软件，里面有个功能是读取芯片的flash，那个功能是要注册才能使用的，但是jFlash就有这个功能，免注册的。


6、最后，聊聊关于bin和hex的区别问题。先说一下hex，刚开始我以为，在编译时设置flash起始地址，和编译后用jFlash修改hex文件的地址偏移量是一样的效果，但是我错了。对比两个不同起始地址的hex文件就知道，内容完全不同。想想也是，比如里面的函数地址，起始地址不一样，函数的地址也不一样，jFlash软件只是将整个文件的地址偏移了，里面的函数地址他怎么知道如何偏移？然后就扯到bin文件了，传说中，bin和hex的区别，就是bin不带地址。然后问题来了，如果bin不带地址，那靠外部的转换软件强行指定地址，是不是一样有问题？DFU软件中有将bin文件转为dfu文件的功能，但是里面显然是要我们提供一个bin文件集合，这是怎么回事呢？我的本意是，我想原来的APP代码整体原封不动，地址总是从0开始，仅靠外部工具将其转换为对应于dfu所需的文件，这样我的APP代码可以兼容所有情况，减少维护难度。

k-ad

谢谢分享，很强大

sf116

完美解决