PIC18F45K50 0x4000以上的存储器显示为0x00

引导程序代码丢失的链接可以通过Google FodioLAN-PLUS2和链接到GITHUB来找到。显然我不能在这里链接？



      以下为原文

    The missing link to the bootloader code can be found by googling for
diolan-plus2 and following the link to github. Apparently I cannot post
links here?
 

你用什么来读闪存？



      以下为原文

    What are you using to read the flash memory?

我认为你描述的iStTPS://GITHUBCOM/NYHOKU/DIOLAN-PLUS在22年前的链接看起来是最后一次更新。http://www. McCHIP.COM/FoMss/FordPase/77101和http://www. McCHIP.COM/FuMss/FordPase/780169可以提供关于您的发布问题的一些见解。



      以下为原文

   
I think the link you describe is https://github.com/nyholku/diolan-plus2
2 years ago looks to be the last update.

http://www.microchip.com/forums/FindPost/777101
and
http://www.microchip.com/forums/FindPost/780169
may provide some insight about your posting problems.

谢谢吉姆的帮助，这是正确的链接。谢谢你给我们工作的提示。



      以下为原文

    Thanks Jim for the help, that is the correct link.
And thanks for the hints on posting workarounds.
 
wbr Kusti
 

错过了杰克@ KkStack的评论。我使用DIALOAN BoooDad代码（我也用它来编程芯片）来读取内存的内容，以验证编程是否正确。由于存在密码/解密，我当然不能直接看到内存内容是什么，而是读取内存并在PC上解密它（实际上是MAC），我看到0x4000以上的内存都是0x00。我还测试了擦除整个芯片（不是大容量擦除，因为它自然不能通过Bootloader获得），低于0x4000的所有东西都是0xFF和0x00以上。我想下一步做一个测试，用CIPIT2/PK2CMD擦除和读取内存，然后尝试编程way.wbr Kusti。



      以下为原文

    Missed the comment by jack@kksound sorry.
I use the dialoan booloader code (which I use to program the chip as well) to read back the contents of the memory in order to verify that the programming works correctly. As there there is crypting/decrypting involved I cannot of course see directly what the memory contents was but reading back the memory and decrypting it on the PC (well Mac actually) I see that the memory above 0x4000 is all 0x00.  I also tested erasing the whole chip (not bulk erase because that is naturally not available via the bootloader) and everything below 0x4000 is 0xFF and above 0x00.
 
I think I will next do a test to erase and read back the memory using PICKit2/pk2cmd and then try to program it that way.
 
wbr Kusti
 

好主意，它听起来更像是Bootloader的回放函数中的一个bug。



      以下为原文

   
Good idea, it sounds more like a bug in the bootloader's readback function.
 

好主意，它听起来更像是Bootloader的回放函数中的一个bug。这正是我下一步要做的。



      以下为原文

   
Good idea, it sounds more like a bug in the bootloader's readback function.
 


That is exactly where I was going next.....

Bootloader回放是我的第一个嫌疑犯，但是我已经过了CyoDE，没有任何东西可以在任何范围内提出任何不同的地址，所有的地址看起来都是完全独立的。用PICTIT2/CMD读回，确认上面的0x4000看起来像是0x00，表明芯片级别机制在起作用。用PICTIT2/PK2CMD擦除和回放显示内存在那里，0xFF到处都是从0x00到0x8000。所以基本上AFAIS有以下原因：内存读回为0x00 .1）错误的芯片-检查（除非它是伪造的，不要这样认为）2芯片问题-测试了几个芯片，勘误表提到，注意三）EBTR机制是踢（CPN在正常模式AFAIU没有影响），所以我把注意力转向配置位和这个这就是我发现的问题：PK2CMD没有正确地编程CPN、WRTN和EBTNNIT。我像这样编程芯片：有什么不对吗？另一个问题是：我也有了CIPIT3，这是我一生中使用过的一次，因为我不喜欢MPLAB IPE。但是，为了调试这个问题，我尝试了它，却一无所获。它声称，当连接到同一个ICSP报头时，它不能检测目标VDD，其中PICTIT2没有问题。这两个程序员在ICSP中需要的是不同的还是我的PICTIT3损坏了？现在，我试图回忆过去，我似乎记得原来的PKC2M不支持PIC18F45 K50，我清除了PK2DEVICE文件。这可能是问题所在吗？如果有的话，想知道在哪里得到一个功能文件或修复？（300007）除300007以外的所有数据都与数据表完全一致。根据数据表300007未实现并应读取为00（它确实如此），但数据表还列出默认值/未编程值，如FF；必须是文档错误，FF未被校正为其他未被标记的位。D读00



      以下为原文

    The bootloader readback was my first suspect also but I've been over the
code and there is nothing that would suggest anything different for
addresses in any range, everything seems to be totally independent
of the address. Reading back with PICKit2/cmd just confirmed that
the above 0x4000 looks like 0x00 suggesting that a chip level
mechanism is at work.
 
Erasing with PICKit2/pk2cmd and reading back shows that the memory is there,
0xFF everywhere from 0x0000 to 0x8000.
 
So basically AFAIS there are the following reasons for memory reading back as 0x00.
 
1) Wrong chip -- checked (unless it is a counterfeit, don't think so)
2) Chip problem -- tested with several chips, errata mentions noting like that
3) EBTR mechanism is kicking in (CPn has no effect in normal mode AFAIU)
 
So I turned my attention to the CONFIG bits and this is  what I found:

 
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D
-----------------------------------------
00 25 5F 3F 00 D3 A5 00 0F C0 0F E0 0F 40 -- after pkcmd -e (bulk erase) (*)
23 68 5F 3C -- D3 81 -- 00 80 0F 80 0F 00 -- CONFIG bits in bootloader.hex file
23 68 5F 3C 00 D3 81 00 01 80 03 80 03 00 -- after pgramming bootloader.hex with pkcmd
23 68 5F 3C 00 D3 81 00 01 80 03 80 03 007 -- after bootloader has programmed the chip
 

 
So I guess the problem is that the pk2cmd does not program the CPn,WRTn and EBTRn
bits correctly.
 
I program the chip like this:
 

 
./pk2cmd -b. -fbootloader.hex -pPIC18lf45k50 /m /e /j /r
 

 
Anything wrong with that?
 
A side question: I've also got PICKit3 which I've used like once in my life cause I do not like the MPLAB IPE.
 
But to debug this problem I tried it and got nowhere fast. It claims that it cannot detect target VDD when
connected to the same ICSP header where PICKit2 has no problems. Do those two programmers differ in
what they require from the ICSP or is my PICKit3 damaged?
 
Now that I try to recall the past I seem to remember that originally pkc2m did not support PIC18F45K50
and I scavenged the PK2DeviceFile.dat to do that from somewhere in the interweb ... could that be
the problem? If so any idea where to get a functional file or fix that?
 
 
 
 
 
 
 

(*) All except 300007 look exactly as per data sheet.
According to data sheet 300007 is not implemented
and should read as 00 (which it does) but the data
sheet also lists the default/unprogrammed value as FF;
must be documentation error and the FF is not correct
as all other bits marked as unimplemented read 00

用这个程序Pk2DeFieldFieldIdter查看PK2设备文件，我看到PIC18F45 K50的内存大小被列为0x00 000 4000，这显然是不正确的，并且这样的气味可能是问题，将尝试编辑它，然后再试一次！嗯，似乎有一些配置掩码，配置空白，CPMASE和CPCONTIONPARAMATER，这可能是相关的，需要更多的谷歌。



      以下为原文

    Looking at the PK2Device file with this program pk2devicefileeditor I see that
the memory size for PIC18F45K50 is listed as 0x00004000 which is obviously
not correct and smells like this could be the problem, will try to edit that
and try again!
 
Hmmm there appears to be some ConfigMasks,ConfigBlank,CPMask and CPConfig
paramaters which maybe related, need to google some more.
 

嗯，我在PK2DeFielFiel.DAT中更改了：并且也固定了我的命令行来使用正确的芯片；但是没有改变前面的配置位完全读回，我不能编程或读取0x4000以上的内存，因此令人沮丧的是，这看起来就是这样。哦，好吧，低速运行。4WD和放在雪链上…WBR库斯蒂



      以下为原文

    Hmm, I changed in PK2DeviceFile.dat to:
 

CPMask = 0x400F 
ProgramMem = 0x00008000

 
and also fixed my command line to use the correct chip ;) 
 

./pk2cmd -b. -fbootloader.hex -pPIC18f45k50 /m /e /j /r

 
But nothing changed the config bits read back exactly as before
and I cannot program or read the memory above 0x4000,
so frustrating, this so much looked like this would be it.
 
Oh well, engage the low speed 4WD and put on the snow chains...
 
wbr Kusti
 

好的，我看到的是用单词表示的，所以0x00 000 4000看起来是正确的，但没有区别。4550也似乎应该是正确的。



      以下为原文

    Ok, I see the 
ProgramMem


is expressed in Words so 0x00004000 would appear to be correct but makes no difference.

Also 4550 seem to useCPMask = 0x400F

so that should be correct

更多的测试：我从.Hoto删除了Case0x3000、0x3000、0x3000 C的值，防止PK2CMD对这些位置进行编程，现在这些位置（以及其他所有东西）看起来都很好。因此，我认为这与PK2CMD可能与PK2DEVICEFIL.DAT文件有关。至少现在我有一份工作。



      以下为原文

    More testing:
 
I removed the values for CONFIG 0x300008,0x30000A,0x30000C from the .hex 
to prevent pk2cmd from programming those locs and now those locs (and everything else)
looks alright.
 

23 68 5F 3C 00 D3 81 00 0F 80 0F 80 0F 00 

 
So definitely I think this is something to do with the pk2cmd probably with the PK2DeviceFile.dat file.
 
At least now I have a work around.
 

我也有一个皮卡3，因为我不喜欢MPLAB IPE，所以我在生活中使用过一次。你有一个真正的皮卡3，不使用它吗？掏出50美元是最困难的部分，你已经过去了。微笑：不喜欢IPE？那是亵渎神明。它比MPLAB X IDE有更多的编程特性。在一个已知的好的MCU和简单的接口（测试板）上测试你的皮卡3和IPE。如果你有一个板和MCU，你需要更多的东西。学习PIC的必要的邪恶。



      以下为原文

     
'I've also got PICKit3 which I've used like once in my life cause I do not like the MPLAB IPE.'
 
You have a genuine PICKit3 and don't use it?
 
Shelling out the $50 is the hard part and you've gotten past that.Smile:
 
Don't like IPE?
 
That's blasphemy. It has way more features for programming than MPLAB X IDE.
 
Test your PICKit 3 and IPE on a known good MCU and simple interface(breadboard).
 
If all you have is this one board and MCU you 'need more stuff'.
 
Necessary evil of learning PIC's.

哎呀。看来你解决了自己的处境。不顾。



      以下为原文

     
Oops. Looks like you solved your situation. Disregard.

保持自由，没错，真正的皮条3。我不喜欢是因为没有PK3CMD，当我得到PACTIT3时，没有命令行工具可用于Mac，所以对于我的工作流程来说，这基本上是NoGo。现在我相信IPE可以在命令行模式中使用，但是当PACKIT2已经服务了5年的时候，为什么要麻烦……是的，我有几块木板和一块面包板，但是没有乐趣。至于这个问题，我不会叫它解决。我可以忍受它，但我想找到它的底部，并妥善解决它。所以我继续挖掘…欢呼



      以下为原文

    Hi Captain Freedom,
 
Yeah, genuine PICKit3 alright. My dislike is because of there is no pk3cmd and when I got
the PICKit3 no command line tool was available for Mac so this was basically no
go for my workflow. Now I believe IPE can be used in command line mode but
when PICKIt2 has served perfectly for +5 years, why bother...
 
Yeah, I've got a few boards around and a bread board one too, but no joy.
 
As to the problem, I would not called it solved ... I can live with it but I would
like to get to the bottom of it and solve it properly. So I keep digging...
 
cheers Kusti
 
 
 

Kusti“找到它的底部并正确地解决它”早些时候你说你的引导装载程序是加密的。这听起来不好。我检查了我们计划使用的一个。没有加密。在十六进制，但不加密。很难找出它做或编辑，除非你想学习机器代码过夜。将给出更充分的反应明天。



      以下为原文

     
Kusti
 
"get to the bottom of it and solve it properly"
 
Earlier you said your bootloader was encrypted.
 
That doesn't sound good.
 
I checked one we plan to use.
 
Not encrypted. In hex but not encrypted.
 
Be tough to figure out what it does or edit unless you want to learn machine code overnight.
 
Will give fuller response tomorrow.