PIC18F67K40的MCC引导加载程序出错

主机所做的第一件事是检查引导加载程序版本。虽然get版本返回一些有用的信息，但它也验证了COM是好的。在这种情况下，通信系统不是，所以我们需要弄清楚原因。建议*确保Tx和RX（TXEN和CREN）启用EUSAT。*验证PPS被正确配置以将信号路由到外围设备。*验证引脚上的模拟禁用。



      以下为原文

    The first thing the host does is to check the bootloader version.  While the Get Version returns some useful information, it also verifies that comms are good.  It seems in this case comms are not.
 
So we need to figure out why.  Suggest
*  Ensure EUSART is enabled for Tx and Rx  (TXEN and CREN).
* Verify PPS is configured properly to route the signals to the peripheral.
* Verify analog disabled on the pins

嗨，丹诺，谢谢你的回复。在我现在纠正的MCC配置中确实有一个明显的错误（Bootloader错误UART）。不幸的是，引导加载程序仍然不能正常工作。在“Bootloader版本读取成功”之后，统一的主机应用程序立即失败。我已经附加了更新的项目文件，以便其他人可以重新创建该行为。在调试Bootloader时，我的下一步应该是什么？谢谢。



      以下为原文

    Hi Danno,
 
Thanks for your reply.
 
There was indeed a glaring error in the MCC configuration that I've now corrected (wrong UART for the bootloader).
 
Unfortunately the bootloader is still not functioning correctly. The Unified Host Application now fails consistently immediately after "Bootloader Version Read Successful".
 
I've attached the updated project files so others can recreate the behavior.
 
What should be my next step in attempting to debug the bootloader?
 
Thanks.
 
   Attached Image(s)


Attachment(s)

PIC18F67K40_20170623.zip (140.78 KB) - downloaded 75 times

嗨，我面临着同一个问题18F47 K40。你可能想看看这个帖子：HTTP://www. McCHIP.COM/FUMMS/M960192.ASPXCHESS。



      以下为原文

    Hi,
 
I faced the same issue with the 18f47k40.
You might want to have a look into that post :http://www.microchip.com/forums/m960192.aspx
 
Cheers.

我回顾了赛贝斯特的帖子。我认为我已经发布的代码已经修改了注册名称等。正如刚才所建议的，刚才我使用了一些软件，在引导程序应用程序时，偷听了PC和PIC之间的串行通信。下面的日志显示了在PC和PIC之间传递的数据，只是为了澄清事件的顺序：1。单击统一主机应用程序中的“程序设备”按钮。2。统一主机应用程序控制台日志报告：3。在“Bootloader版本读取成功”之后，统一主机应用程序报告“编程失败后断开连接”。现在真的卡住了。



      以下为原文

    I reviewed SebKister's post. I think the code I've posted already has the modifications to register names, etc. as suggested there.
 
Just now, I tried using some software that eavesdrops on the serial communication between the PC and the PIC when the bootloader application. The following logs show the data passed between the PC and PIC.
 
Just to clarify the sequence of events:
1. Click the "Program Device" button in the Unified Host Application.
2. Unified Host Application console log reports:

09:31:22.361 > Device: COM4 Bootloading started
09:31:22.477 > Reading Version ...
09:31:22.520 > Bootloader Version Read Successful

3. Immediately after "Bootloader Version Read Successful", Unified Host Application reports "Disconnected after Programming Failed."
 
Send log from the serial sniffer software:

000132: 2017-06-26 09:31:22.4785406 +0.1078131
55 00 00 00 00 00 00 00 00 00 U.........

 
Read log:

000213: 2017-06-26 09:31:22.5173427 +0.0000027
55 00 00 00 00 00 00 00 00 00 19 00 00 01 00 00 U...............
C0 6A 00 00 80 80 AA FF 3F F7 Àj..€€ªÿ?÷

 
I appreciate everyone looking at this. Really stuck right now.

嗨，我不会坚持使用统一的引导加载程序。有一些事情不会发生，因为它应该从我看到的反编译应用程序中增加TrutADVIEWONE（）函数。我很高兴被证明是错误的，但到目前为止还没有人。也许丹诺可以？你最好自己编写Bootloader主机。



      以下为原文

    Hi,
 
I would not insist using the unified bootloader. There's something not going as it should in createAllExceptReadVersion() function from what I saw decompiling the app. I'd be happy being proven wrong on that one but no one has so far. Maybe Danno can ? You'd better off coding your own bootloader host.
Cheers

嗨，SebKister，正如我在我的第一篇文章中提到的，我以前成功地获得了与PIC18F45 K22一起工作的MCC引导加载程序。我当时使用的统一主机应用程序的版本是我现在试图使用PIC18F67 K40的相同版本。由于整个系统与45 K22工作正常，从那时起我唯一改变的是芯片（67 K40）和MCC Bootloader代码，我假设问题在PIC C代码的某个地方。我们计划在稍后的时间为这个项目编写自己的Bootloader主机应用程序。CT，但现在我希望能够使用Microchip的版本测试C代码在PIC…



      以下为原文

    Hi SebKister,
 
As I mentioned in my very first post, I was previously successful getting the MCC bootloader working with the PIC18F45K22. The version of the Unified Host Application I was using at the time is the same version I'm trying to use now with the PIC18F67K40. As the whole system was working properly with the 45K22 and the only things I've changed since then are the chip (67K40) and the MCC bootloader code, I was assuming the problem was in the PIC C code somewhere.
 
We are planning to code our own bootloader host application at a later date for this project, but for now I was hoping to be able to use Microchip's version to test the C code on the PIC...

主机版本0.1.3真的很旧。0.1.8是在同一页上发现用户指南（www. McCux.com／Bootloader），然后链接到8位。



      以下为原文

    Host version 0.1.3 is really old.  0.1.8 is on the same page where you found the User's Guide (www.microchip.com/bootloader) then follow the link to 8 bit.

尝试使用0.1.8版本，并且与版本0.1.3有相同的结果：控制台：22:01: 15.448和gt；设备：COM15引导加载SistDe22:01: 15.607 & gt；读取版本…22:01: 15.650和gt；Bootloader版本读取成功，这就是控制台。主窗口显示状态：在编程失败后断开连接。从主机代码的观点来看，这仍然意味着我们没有获得PASCREATEAL异常TRAADADVIEWONE（）；这是在一个生产单元/固件上测试的，它使用MCC生成的BooToA通过3个更新周期而没有问题。Der代码，带有一个定制的引导加载程序主机。我认为对于所有的人都有一个积极的计划，比如一个项目（统一的引导加载程序），它可以根据每个人的需要被改编、调试或用作一个快速启动框架。



      以下为原文

    Tried with version 0.1.8 and I have the same result as with version 0.1.3 :
 
In the console :
22:01:15.448 > Device: COM15 Bootloading started
22:01:15.607 > Reading Version ...
22:01:15.650 > Bootloader Version Read Successful
That's it for the console. The main windows shows Status : Disconnected after programming failed.
 
From the host code point of view that still means we are not getting past createAllExceptReadVersion();
 
This was tested on a production unit/firmware that went without problem through 3 update cycles using the MCC generated bootloader code, with a custom bootloader host.
 
I think it would be positive for all sides to have a project like this one ( the unified bootloader) available on a repo so that it can be adapted,debugged, or used as a quick start frame, according to everyone's need. 
 
 
 
 
 

我可以用Bootloader主机应用程序的版本0.1.8重复我的问题。在控制台达到“引导加载程序版本成功”之后，主窗口状态立即显示“编程失败后断开”。除了编写自定义的主机应用程序之外，还有其他方法吗？验证我的问题是否存在于主机应用程序或MCC生成代码中？



      以下为原文

    I was able to repeat my issue with version 0.1.8 of the bootloader host application. 
 

07:59:44.278 > Device: COM4 Bootloading started
07:59:44.283 > Reading Version ...
07:59:44.352 > Bootloader Version Read Successful

 
Main window status immediately shows "Disconnected after Programming Failed" after the console reaches "Bootloader Version Read Successful".
 
Apart from writing a custom host application, is there any other method to verify whether my problem lies in the host application or the MCC generated code?

你可以调试/跟踪你的引导加载程序，看看它是主机停止正常的通信流。如果你希望我能给你一个我的Bootloader主机的草稿，这样你就可以在你的配置上测试它。



      以下为原文

    You could probably debug/trace your bootloader and see that it's the host that stops the normal communication flow.
If you wish I can PM you a draft of my bootloader host so you can test it on your config.
Cheers
 

短版：UMM…这很尴尬。生成的Bootloader和发布的主机不能与PIC18FXXK40设备一起工作。更长的版本：问题是K40设备比我们预期的更大（0x2000 b），擦除行和写锁存器比任何其他8位MCU都要大。如果你在内存中找到了γ定义，它可能会工作。H到一半的现有值，并将项目代码限制在64KB（0x10000）内存中。我们正在努力解决这个问题并得到一个新的发布。



      以下为原文

    Short version:  Umm... this is embarassing.  The generated bootloader and released host doesn't work with the PIC18FxxK40 devices.  
 
Longer version: The problem is that the 'K40 devices are bigger (0x20000B) than we ever expected and erase rows and write latches are larger than any other 8 bit MCU.  It might work if you find the #defines in memory.h to half of the existing values, and limit project code to the first 64KB (0x10000) of memory.
 
We are working to solve the problem and get a new release out.

感谢丹确认主机应用程序被窃听。从你的答案，我猜这个应用程序也不会开源。我希望这个问题会得到解决，尽管我在半年前就表明了这一点……仍然相信这是一个资源的腰部…尤其是当问题影响到另一个伟大的芯片系列（K40）。



      以下为原文

    Thanks Dan for the confirmation that the host app is bugged. From your answer I guess also that the app won't get open sourced. I'm hopeful the issue will be fixed although I signaled it half a year ago...Still believe this is a a waist of resources... especially when the problem affects an otherwise great chip serie (the K40).

成功！基于丹诺关于内存中的内存大小减半的建议。h，现在我有了引导加载程序。我将更新我的项目文件，以帮助任何其他遇到这个问题的人。我还附上了主机应用程序窗口的设置和控制台日志的截图。修改的细节对我的工作如下：1。在生成MCC Bootloader PIC代码后，更新Pix18FyBootload.C中的更新寄存器名称和引用，如SebKister在2016年11月发布的文章中所描述的：2。如丹诺所建议的，更新在内存中定义的y. h值如下：3。在PIC应用程序（我所附样本中的Clkel2BlnKy）的配置下，在XC8全局选项-GT；XC8链接器& GT；内存模型中，将ROM范围设置为0 FFFF，如附图截图所示。从这里，您应该能够编译并烧毁MCC Bootloader，编译PIC AP。PrPosits，然后使用统一的主机应用程序将PIC应用程序加载到PIC18FXXK40，并附带了屏幕截图中所示的设置。这种解决方案的主要后果是，如果您使用组合，您只能访问PIC18FXXK40中的Flash程序存储器的一半。MCC Bootloader + Microchip统一主机应用程序。在我的情况下，这对我的申请来说还远远不够。非常感谢塞贝克斯特和丹诺在这个问题上的帮助。在将来看到MCC Bootloader代码的工作是不需要修改的，并且统一的主机应用程序与较大的程序存储空间一起工作是很好的。



      以下为原文

    Success! Based on Danno's recommendation about halving the memory sizes in memory.h, I now have the bootloader working.
 
I'm attaching my updated project files for the benefit of anyone else who comes across this issue. I'm also attaching a screenshot of the host application window with settings and console log.
 
Details of the modifications that worked for me are below:
 
1. After generating the MCC bootloader PIC code, update register names and references in pic18f_bootload.c as described by SebKister in his post from November 2016: http://www.microchip.com/forums/m960192.aspx
2. As suggested by Danno, update the #defines in memory.h to the values below:

#define WRITE_FLASH_BLOCKSIZE 64
#define ERASE_FLASH_BLOCKSIZE 64
#define END_FLASH 65536

3. In the configuration of PIC application project (clicker2_blinky in my attached sample) under XC8 global options -> XC8 linker -> Memory model, set ROM ranges to 0-FFFF as shown in the attached screenshot.
 
From here, you should be able to compile and burn the MCC bootloader, compile the PIC application, and then load the PIC application to the PIC18FxxK40 using the Unified Host Application with the settings shown in the attached screenshot.
 
The main consequence of this workaround is that you have access to only half of the flash program memory in a PIC18FxxK40 if you use the combination of MCC bootloader + Microchip Unified Host Application. In my case, this is still more than sufficient for my application.
 
Many thanks to SebKister and Danno for their help on this problem!
 
It would be nice in future to see the MCC bootloader code work as generated without needing modifications and the Unified Host Application work with larger program memory spaces.
   Attached Image(s)


Attachment(s)

PIC18F67K40_20170629.zip (140.89 KB) - downloaded 95 times