lpc17xx内部Flash问题

只看该作者 · 2009-12-18 09:40

使用FlashMagic下载hex文件到lpc1766中，然后又在FlashMagic中读出内部Flash的数据，发现在地址为0x0000001c处的后4字节数据并不是hex文件的对应地址的数据，而且不同的工程hex文件中，此地址的数据并不相同。请问这是为什么，怎么得出此地址的数据值。谢谢！

只看该作者 · 2009-12-18 12:03

FlashMagic自动执行了代码有效性字节的计算。如果有使用过LPC2000系列经验的话就应该知道这个东西了。
怎么得出此地址的数据值？自己写个小工具计算，一般情况下没有必要，因为一般调试器后者FLASHMAGIC都会自动计算并更正这几个代码有效性字节。（题外话，对于LPC13XX系列如果使用USB方式下载的话，这个代码有效性矫正工作就非常重要了，NXP可以考虑写个支持命令行的checksum utility之类的工具来自动生成带有代码有效字节的BIN文件）
以下内容摘自LPC1700的UM：
3.1.1 Criterion for Valid User Code
The reserved Cortex-M3 exception vector location 7 (offset 0x 001C in the vector table)
should contain the 2’s complement of the check-sum of table entries 0 through 6. This
causes the checksum of the first 8 table entries to be 0. The boot loader code checksums
the first 8 locations in sector 0 of the flash. If the result is 0, then execution control is
transferred to the user code.

只看该作者 · 2009-12-18 14:22

感谢bigarmer的提点，问题应该是你说的那样。
查看LPC1700的UM后还是有些不明白，想再请问一下怎么通过hex文件中数据得出这个有效性字节数据？

只看该作者 · 2009-12-18 16:28

2楼摘出来的内容就是解释如何计算这4个字节的代码有效性数据的原理啊。意思就是从0开始的8个字（32字节）的累加和要为0，其中0-6字（28字节）内容是固定的异常向量表，而0x1C地址是预留字，NXP利用这个预留字做了这么个功能，要计算这个地址上的值，实际上就是前0-6字累加和的2的补码，比如前0-6字的累加和为n，那么0-n则为0x1C地址要写入的东西（注意ARM采用的是小端模式）。LPC2000上则是以0x14处的4个字节作为代码有效性验证字节。你自己可以验证一下。
如果用代码解，那么参考如下：
n = *((unsigned long *)(buf + 0x00)) +
      *((unsigned long *)(buf + 0x04)) +
      *((unsigned long *)(buf + 0x08)) +
      *((unsigned long *)(buf + 0x0C)) +
      *((unsigned long *)(buf + 0x10)) +
      *((unsigned long *)(buf + 0x14)) +
      *((unsigned long *)(buf + 0x18));
      *((unsigned long *)(buf + 0x1C)) = 0 - n;  // Signature at Reserved Vector

只看该作者 · 2009-12-18 16:49

是的，按照bigarmer的意思，加入hex文件中的数据，得出了相应的结果。
非常感谢bigarmer！

lpc17xx内部Flash问题

相关下载

相关帖子

常驻人口

技术高手奖章