完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
电子发烧友论坛|
你好，我在连接的汽车应用中使用了一个DSIC33 FJ256GP506A。为了允许OTA更新，我们在较低和较高的空间中分割闪存。您可以在附件中找到相应的GLD-文件。在这个项目中，几乎所有的程序内存（~ 90%）都被使用在ProjTythDasBo.jpg.上星期我注意到一些奇怪的行为：如果我正在更新（在空中）控制器上的下一个区域，所有的工作都在意料之中，但是更新上面的区域（从0x15800开始）程序。M不能正常工作（开始例程会产生一些错误）。在用PIC内存查看器分析产生的十六进制文件之后，我注意到在上面区域中的一些指令在另一个区域中比在较低的存储器中低，例如：较低（第一列是地址）：02F500FFFF 07FFF 04F5F 006373……嗯……02F586C6900616C 06F74 004672 IL。……02F60 006961 000 6C 0415F 006464 AI…L。A…D。02F68 006572 007373，007245呃…上：27 E68 000 FFFF 77FFF 006373 F4F…嗯……25E70 06C6900616C 06F74 004672 IL。……2E78 78 000 000 6C 00 415F 006464 AI…L。A…D。27 E80 006572 007373，007245呃…实际上，指令应该有0x15000的偏移量，但是正如你所看到的，偏移量要高得多。你知道为什么有些指令被移到另一个区域吗？（在这个例子中，几乎到输出文件的末尾）最好的问候，托马斯
Amithasggp33 FJ256GP506AAUPIPROMMET.TXT（65.86 KB）-下载99次 以上来自于百度翻译 以下为原文 Hi, I'm using a dsPIC33FJ256GP506A in a connected car application. In order to allow OTA - Updates we split the flash memory in an lower and upper space. You can find the corresponding GLD - files in the attachment. In this project almost the whole program memory (~90%) is used as you can see in project_dashboard.JPG. Last week i noticed some stange behavior: If I'm updating (over the air) the lower area on the controller everything works as expected, but updating the upper area (starting at 0x15800) the program doesn't work properly (start routine produces some error). After analyzing the produced HEX files with the PIC memory viewer, I noticed that some instructions in the upper area are in another area than in the lower memory, e.g.: Lower (first column is address): 02F50 00FFFF 007FFF 004F5F 006373 ....... _O..sc.. 02F58 006C69 00616C 006F74 004672 il..la.. to..rF.. 02F60 006961 00006C 00415F 006464 ai..l... _A..dd.. 02F68 006572 007373 007245 006F72 re..ss.. Er..ro.. Upper: 27E68 00FFFF 007FFF 004F5F 006373 ....... _O..sc.. 27E70 006C69 00616C 006F74 004672 il..la.. to..rF.. 27E78 006961 00006C 00415F 006464 ai..l... _A..dd.. 27E80 006572 007373 007245 006F72 re..ss.. Er..ro.. Actually the instructions should have an offset of 0x15000, but as you can see the offset is much higher. Do you know why some instructions are moved to a different area? (in this example almost to the end of the output file) Best Regards, Thomas Attached Image(s) Attachment(s) ame_asg_p33FJ256GP506A_lower_mem.txt (65.86 KB) - downloaded 71 times ame_asg_p33FJ256GP506A_upper_mem.txt (65.86 KB) - downloaded 99 times 
0
|
|
相关推荐
19个回答
|
|
|
这些似乎不是指令。所有的上字节都是零。最有可能的是，这是某种数据。而且，如果从六文件中得到这个，在十六进制文件中，所有的地址都是加倍的。
以上来自于百度翻译 以下为原文 These don't appear to be instructions. All the upper bytes are zeroes. Most likely this is some sort of data. Also, if you get this from a HEX file, in the HEX file all the addresses are doubled. |
|
|
|
|
|
或文本：是：“振荡器失败”“地址Erro”
以上来自于百度翻译 以下为原文 or text :) _O..sc.. il..la.. to..rF.. ai..l... _A..dd.. re..ss.. Er..ro.. is: "Oscillator Fail" "Address Erro" |
|
|
|
|
|
你是对的，那些是文本，没有指令，但问题仍然是一样的。程序（XR）：Oracle＝0x15800，长度＝0x15000……建立输出：程序存储器[Oracle＝0x15800，长度＝0x15000 ]段地址长度（PC单元）长度（字节）（-DEC）--------------------------------Text 0x15800 0x211C 0x31 AAA（12714）。37）DIIT 0x25ABA 0x2D6 0x44 1（1089）。文本0x25D900169A 0x21E7（8679）。const 0x29 C48 0xBB8 0x1194（4500）使用的总程序存储器（字节）：0x1BBD3（113619）88%个十六进制文件：……2A68044F5F 006373 06C6900616C…IL…2A68 800 6F74 004672…哎…2A69000 415F 006464 006572 007373 A A。重新…2A698 007245 06F72 000072………2A6A0 006174 06B63 007245 06F72 TA。呃………如果你可以看到地址，如果“指令”在内存之外。我使用过多的程序内存吗？最好的问候，托马斯
以上来自于百度翻译 以下为原文 You're right, those are texts and no instructions, but the problem is still the same. Build GLD: ........... program (xr): ORIGIN = 0x15800, LENGTH = 0x15000 .......... Build Output: Program Memory [Origin = 0x15800, Length = 0x15000] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x15800 0x211c 0x31aa (12714) .text 0x1791c 0xe19e 0x1526d (86637) .dinit 0x25aba 0x2d6 0x441 (1089) .text 0x25d90 0x169a 0x21e7 (8679) .const 0x29c48 0xbb8 0x1194 (4500) Total program memory used (bytes): 0x1bbd3 (113619) 88% HEX - file: ............ 2A680 004F5F 006373 006C69 00616C _O..sc.. il..la.. 2A688 006F74 004672 006961 00006C to..rF.. ai..l... 2A690 00415F 006464 006572 007373 _A..dd.. re..ss.. 2A698 007245 006F72 000072 00535F Er..ro.. r..._S.. 2A6A0 006174 006B63 007245 006F72 ta..ck.. Er..ro.. ........ As you can see the address if the "instruction" is outside of the memory. Do i use too much program memory? Best Regards, Thomas |
|
|
|
|
|
外面有什么记忆？从报告中看，这意味着“.const”部分从0x29 C48扩展到0x2A7FF，并且这些地址（2A680）在该范围内。
以上来自于百度翻译 以下为原文 Outside what memory? From the report: .const 0x29c48 0xbb8 0x1194 (4500) That means the ".const" section spans from 0x29c48 to 0x2A7FF, and those addresses (2A680) are in that range. |
|
|
|
|
|
谢谢你的回答！然后，我必须将长度0x15000乘以3（1地址引用三字节）以获得最大字节大小？
以上来自于百度翻译 以下为原文 Thank you for the answer! Then i have to multiple the LENGTH 0x15000 by 3 (1 address refer three bytes) to get maximum size in bytes? |
|
|
|
|
|
|
|
|
|
|
|
如果我看HEX文件，一行有12个字节。我错了吗？为什么乘以2？2A6000 04F5F 006373 06C6900616C…IL…La…2A68 800 6F74 004672…A.L.…2A69000 415F 006464 006572 007373 A A…D。R.SS…2A698 007245 06F72 000072 0535F ER…Ro…R... .. 2A6A0 006174 06B63 007245 06F72 TA…如你所看到的，在附加的映像程序存储器中，闪存的容量为0xA800字，因此有15000字节。
以上来自于百度翻译 以下为原文 If i look at the HEX file, one line has 12 bytes. Am i wrong? Why multiple by 2? 2A680 004F5F 006373 006C69 00616C _O..sc.. il..la.. 2A688 006F74 004672 006961 00006C to..rF.. ai..l... 2A690 00415F 006464 006572 007373 _A..dd.. re..ss.. 2A698 007245 006F72 000072 00535F Er..ro.. r..._S.. 2A6A0 006174 006B63 007245 006F72 ta..ck.. Er..ro.. As you can see in the attached image program_memory.JPG the flash memory has a capacity of 0xA800 words, therefore 15000 bytes? Attached Image(s) |
|
|
|
|
|
这是PIC24架构上“3x2”字节后面的一个古老的故事：你必须相信它，就像一个信仰的问题。
以上来自于百度翻译 以下为原文 This is the old famous story behind "3x2" bytes on PIC24 architecture :) You just have to trust that, like a matter of faith |
|
|
|
|
|
好的，谢谢！在那里我可以找到一些额外的信息给著名的StryPrror：但是有一件事我仍然不理解（就像在第一篇文章中张贴）：在用PIC内存查看器分析生成的HEX文件之后，我注意到上面区域中的一些“指令”（或者这个例子中的文本）是在另一个区域比在较低的内存中，例如：较低（第一列是地址）：02F50000 FFFF 77FFF 04F5F 006373…0. F5866C6900616C 06F74 004672 IL。到…R.02F60 006961 000 6C 0415F 006464 AI…L。A….D.02F68 006572，007373，007245，66F72，…呃…Ro。上：27 E68 000 FFFF 77FFF 006373。..….27 E70 06C6900616C 06F74 004672 IL。到..射频…27 e78 006961 000 000 6000 415F 006464 AI…L。A….D.27 E80 006572 007373，007245呃……事实上，这两个部分都应该具有与它们区域的起始地址相同的偏移量。但是，在这个例子中，在较低的区域，TrimiO.S...是在开始的部分和在上部区域几乎结束？对此有什么解释吗？
以上来自于百度翻译 以下为原文 OK, thank you! Where I can find some additional informations to the famous story Smile: But there is one thing i still not understand (like posted in the first post): After analyzing the produced HEX files with the PIC memory viewer, I noticed that some "instructions" (or text in this example) in the upper area are in another area than in the lower memory, e.g.: Lower (first column is address): 02F50 00FFFF 007FFF 004F5F 006373 ....... _O..sc.. 02F58 006C69 00616C 006F74 004672 il..la.. to..rF.. 02F60 006961 00006C 00415F 006464 ai..l... _A..dd.. 02F68 006572 007373 007245 006F72 re..ss.. Er..ro.. Upper: 27E68 00FFFF 007FFF 004F5F 006373 ....... _O..sc.. 27E70 006C69 00616C 006F74 004672 il..la.. to..rF.. 27E78 006961 00006C 00415F 006464 ai..l... _A..dd.. 27E80 006572 007373 007245 006F72 re..ss.. Er..ro.. Actually both showed parts should have the same offsets from the start address of their areas. But in this example in the lower area the text _O..sc. is at the beginning of the part and in the upper area almost at end? Is there a explanation for that? |
|
|
|
|
|
好啊！现在我没有得到这个部分：你是指那些数据被复制了吗？
以上来自于百度翻译 以下为原文 ok! Now I don't get this part: are you meaning that those data are duplicated? |
|
|
|
|
|
我认为几乎相同的代码加载在上和下区域，因此对于相同的数据，在（下）ADDR位中似乎没有任何差异。这是完全相同的代码吗？如果不是，链接器可以移动周围的东西。
以上来自于百度翻译 以下为原文 I think nearly the same code is loaded in upper and lower areas, so there wouldn't seem to be any difference in (lower) addr bits for the same data. Is it exactly the same code? The linker might move things around if it's not. |
|
|
|
|
|
是的，这是完全相同的代码。只使用不同的GLD文件（见第一篇文章）。
以上来自于百度翻译 以下为原文 Yes, it is exactly the same code. Only different GLD files (see first post) are used. |
|
|
|
|
|
这不是十六进制文件的样子。为什么乘2。表示一个命令需要三字节。但是命令只需要两个地址。3/2＝1.5。为了使事情紧凑，你需要乘以1.5。但那将是非常混乱的。因此，微芯片决定乘以2，并用0填充额外的字节。这不太麻烦。
以上来自于百度翻译 以下为原文 This is not how HEX file looks like. Why multiply by 2. To represent a command you need three bytes. But the command takes only two addresses. 3/2 = 1.5. To make things compact you would need to multiply by 1.5. But that would be very messy. So Microchip decided to multiply by 2 and fill the extra byte with 0. This is less messy. |
|
|
|
|
|
|
|
|
|
|
|
下一个区域的建筑输出看起来怎么样？您向我们展示了const部分中的上部和一些数据。稍后，您在0x26e68显示了相同的数据，这似乎是在第三。文本部分。
以上来自于百度翻译 以下为原文 What does the build output look like for the lower area? You showed us the upper and some data in the .const section. Later you showed us identical data at 0x27e68 which would seem to be in the 3rd .text section. |
|
|
|
|
|
你是如何得到这些数据的？HEX文件格式看起来完全不同，例如：这里的地址是加倍的。例如，上面的片段从0x2D6开始，而不是从0x5ac开始。
以上来自于百度翻译 以下为原文 How did you obtain this data? The HEX file format looks completely different, such as: :1005ac000200fa00000f78001e007800e70f5000e0 :1005bc0001003a0015cea8000080fa0000000600e9 :1005cc000200fa0011cea90011eea90015cea90067 :1005dc0015eea800010037000000000080a82300e1 :1005ec008103200012000700a170800000002c0085 :1005fc0000806800a07088001e0fe8002003200017 Here the addresses are doubled. E.g. the fragment above starts from 0x2d6, not from 0x5ac. |
|
|
|
|
|
OP表示“HEX文件”，但表示数据是从MPLABX内存视图中获取的。我刚刚引用了OP帖子。我理解两者之间的差异，但没有发现它掩盖了这个问题。
以上来自于百度翻译 以下为原文 The OP said "hex file" but remarked that the data was taken from mplabx memory views. I just quoted OP posts. I understand the difference but didn't figure it obscured the problem. |
|
|
|
|
|
只有表读取才能读取程序存储器的高字节的低字节。空间可见度不能。使用的空间将是第三个大。因此，即使地址是16位，两个字节也会占用三字节。试着在Klattu Barada Nikto等const区域中放置一个字符串。Klattu Barada NiktoYou会得到一些像that.latuBaad NktoIt这样的东西。使用Buffin函数。
以上来自于百度翻译 以下为原文 Only table read can read the low byte of the high word of program memory. prog. space visibility can not. Space used will be a third greater. So two bytes will take up three bytes even though the address is 16bit. Try putting a string in const area such as Klattu Barada Nikto. Klattu Barada Nikto You'll get some something like that. latuBaad Nkto It is quite tricky. mov #6,cnt mov #tblpage(constdata),wx mov wx,TBLPAG mov #tbloffset(constdata),wx loop: TBLRDH.b [wx],tmp TBLRDL.b [wx++],[buffer++] TBLRDL.b [wx++],[buffer++] mov.b tmp,[buffer++] dec cnt,cnt bra nz,loop ;buffer="Klattu Barada Nikto" You can do that in C using builtin functions. |
|
|
|
|
|
我用MPLAB内存视图（导入）获得数据。下面是XC16LD 1.31（a）程序存储器[Oracle＝0x400，长度＝0x15000 ]节地址长度（PC单元）长度（字节）（DEC）--------------------------------------0x400 0x211C 0x31 AAA。12714）.conx0x251c0xbc40x11a6（4518）。文本0x1e24e 0x15375（86901）。DIIT 0x1132e 0x2D6 0x44 1（1089）。文本0x11604 0x169a 0x21e7（8679）使用的总程序内存（字节）：0x1bCED（113901）88%。这里您能找到生成的十六进制文件：HTTPS://Drave.GoGoLe.con/Ont？ID= 0B3WY-TZZWAHHYRNH2H2UULRUDKZRJQ
以上来自于百度翻译 以下为原文 I obtained the data with the MPLAB memory view (import). Here is the build output of the lower area: xc16-ld 1.31 (A) Program Memory [Origin = 0x400, Length = 0x15000] section address length (PC units) length (bytes) (dec) ------- ------- ----------------- -------------------- .text 0x400 0x211c 0x31aa (12714) .const 0x251c 0xbc4 0x11a6 (4518) .text 0x30e0 0xe24e 0x15375 (86901) .dinit 0x1132e 0x2d6 0x441 (1089) .text 0x11604 0x169a 0x21e7 (8679) Total program memory used (bytes): 0x1bced (113901) 88% Here can you find the produced HEX - files: https://drive.google.com/open?id=0B3w_TYzWAHIRNHh2UUlRdUkzRjQ |
|
|
|
|
只有小组成员才能发言，加入小组>>
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475 浏览 0 评论
5795 浏览 9 评论
2334 浏览 8 评论
2224 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3530 浏览 3 评论
1125浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
1098浏览 1评论
我是Microchip 的代理商，有PIC16F1829T-I/SS 技术问题可以咨询我，微信：A-chip-Ti
873浏览 1评论
MPLAB X IDE V6.25版本怎么对bootloader和应用程序进行烧录
475浏览 0评论
/9 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
2681
评论
淘帖
4801
