英特尔HEX格式问题

大家好。对不起，如果有一个更好的地方，输出是从XC16，所以我想我粘在这里。我在寻找选项和方法，创建一个引导装载和分发固件更新的一个项目的矿山，我一直在建一个工具，“压缩”产生的“生产十六进制文件”在生成项目时提供AT。基本上只是去除（貌似？）多余的记录，将重置的“扩展线性地址”重置为相同的值，并将更多的指令聚合到单个记录中。这些都是很好的BWT.在HEX文件的末尾是什么看起来是配置位。但我有一个问题，希望有人能回答。以下是我感兴趣的内容：现在我将理解它，我可以删除很多：02行，因为它们只是重复设置目的地址的同一个上面的单词，我们可以把它转换成：我可以将这些进一步聚合到一个记录中，但是我会离开。更接近这一点，第一行（0200 000 0400 02F8）似乎把上面的地址字设置为0x002，这意味着第二行，例如，放在地址0x000 02AFE0（除非IVE得到了我的子孙混合在这里，但我认为我还好……），而值似乎M。我在MPLABX中的配置位窗口中看到了什么（例如，FICD有一个FFCF值，它看起来与上面的第二条记录匹配，只有在小字节中），我不能很好地理解地址如何翻译。在MPLABX，FICD在地址0x157f0……当然，它似乎对我选择的PIC（PIC24EP128）似乎没有意义，但是它非常接近于下一个大小的正确的-PIC24EP256，配置字节开始在0x02AFEC附近。但是，实际上，0x000 02AFE0实际上是在用户程序空间内，最后一页，我相信是正确的（再看数据表）。谁能解释一下这一点，或者指出我在这里的想法出了什么问题？这可能是HEX文件输出中的一个bug吗？0x000 02XXXX似乎不是这个PIC家族的有效地址……但是，看起来我不应该把这些作为软件更新的一部分来写，因为它最终能够实现代码保护，所以也许我只是在我重新工作的输出文件中排除了这些行？谢谢！汤姆



      以下为原文

    Hi all. Sorry if there is a better place for this, the output is from XC16 so I figured I'l stick it here.

Im looking in to options and methods for creating a bootloader and distributing firmware updates for a project of mine, and Ive been building a tool to "compress" the resulting "production hex file" that is provided when you build the project. Basically just removing (seemingly?) superfluous records that keep resetting the "extended linear address" to the same value, and aggregating more instructions in to a single record. Thats all working great btw.

At the end of the hex file are what look to be the configuration bits. But I have a question about what is going on that hopefully someone can answer. Here are the contents that I am interested in:

:020000040000fa
:020000040002f8
:04afe000cfff00009f
:020000040000fa
:020000040002f8
:04afe400efff00007b
:020000040000fa
:020000040002f8
:04afe8006aff0000fc
:020000040000fa
:020000040002f8
:04afec001bff000047
:020000040000fa
:020000040002f8
:04aff00078ff0000e6
:020000040000fa
:020000040002f8
:04aff400ffff00005b
:00000001FF

Now as I would understand it, I can remove a lot of the :02 lines, since they are just repeatedly setting the same upper word of the destination address, and we can turn that in to:

:020000040002f8
:04afe000cfff00009f
:04afe400efff00007b
:04afe8006aff0000fc
:04afec001bff000047
:04aff00078ff0000e6
:04aff400ffff00005b
:00000001FF

I could aggregate those further in to a single record, but I'll leave that alone in this post.

Getting closer to the point, the first line (:020000040002f8) seems to set the upper address word to 0x0002, meaning that the second line, for example, gets placed at address 0x0002AFE0 (unless Ive got my endianess mixed up here, but I think Im ok...)

While the values seem to match what I see in the Configuration Bits window in MPLABX (e.g. FICD has a value of FFCF which seems to match the second record above, only in little endian), I cant quite work out how the address translates. In MPLABX, FICD is at address 0x157F0....?

Certainly it doesnt seem to make sense for my chosen PIC (PIC24EP128), but its very close to being correct for the next size up - PIC24EP256, whos configuration bytes start at around 0x02AFEC. But 0x0002AFE0 then actually ends up within user program space, last page actually, which I believe is correct (looking at the datasheets some more).

Can anyone shed any light on this or point out where Ive gone wrong in my thinking here? Is this a bug in the hex file output perhaps? 0x0002XXXX dont appear to be valid addresses for this family of PIC...

It would seem, however, that I shouldnt be writing these as part of a software update anyway as it would end up enabling code protection, so perhaps I just exclude these lines in my re-worked output file?

Thanks!
Tom