编写PIC32MM系列的引导加载程序找不到任何源文件

你是由MCC Bootloader支持的PIC吗？



      以下为原文

    Is you PIC supported by the MCC Bootloader?

AN1388 PIC32 Bootloader没有官方支持，并且查看MLAYSUB.PDF文件，将USB支持添加到PIC32 MM好奇心板上，但这可能不是引导程序。可能还有一些其他的东西我没有意识到或者没有找到。通过一些原因：开放源码Bootloader指南：http://HADE.MeC.NeWest.EdU/index .php/StudioTyHydBootloader，OnPIC32，创建Bootloader，HyxFielpIC32 32 Bootloader AN1388http://www. MyCHIP.COM/WaveAppNots/AppNot.ASPXAppNeNo.En583636



      以下为原文

    The AN1388 PIC32 bootloader has no official support, and looking at the mla_u***.pdf file, USB support added to the PIC32MM curiosity board but that might not be for the bootloader.

There might be something else that I am not aware of or hasn't found yet.

P.S
My first post had this paralinks that didn't go through for some reason:
open source bootloader guide  - http://hades.mech.northwestern.edu/index.php/Programming_HID_Bootloader_on_PIC32#Creating_Bootloader_Hex_File
PIC32 bootloader AN1388 - http://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en554836

我用和声NVM.C把一个拼凑在一起，然后修改了NVM写函数来支持PIC32 mm。这个可怜的，糟糕的论坛。



      以下为原文

    I kludged one together using Harmony nvm.c , then modified NVM write functions to support the pic32mm. 
 
This poor, poor forum.

重命名为.zip



      以下为原文

    Rename to .zip
   Attachment(s)

somefiles.doc (3.49 KB) - downloaded 79 times

这些只是帮助文件，你必须自己做这些工作来整合。



      以下为原文

    These are only helper files, you'll have to do your own work to integrate this.

嗨，Friesen。在阅读了关于这个主题的各种帖子之后，我还没能使我的引导加载程序正常工作。我的不足。我不停地发布我的帮助请求，没有任何回应。最后有人打了一拳。谢谢你的回答。我下载了你的文件，但我不知道为什么我不能打开它。我会解释我的问题，希望你能给我一个建议。作为IV，我也使用PICT32 MM02506GPM064在MaultDeBoo板上使用MPLABX 4.05和XC32 1.44（免费版本），我试着从USB FLA上闪动我的应用程序。通过Bootloader的SH内存。MPLABX程序员（或IPE）闪亮的统一版本（Boot+App）工作良好：它正确地从启动到APP跳跃：当我尝试通过Bootloader从USB闪光灯上闪动应用程序时，情况不一样。当写入后，我执行验证；出现异常（数据总线）。当我尝试读取总是以0x…4结尾的相同地址时发生错误。因为：链接器生成的六个文件的数据记录可以长达4个32位字，一些数据记录起始于地址字段等于0x……4或0x……C -该设备需要一次写入两个32位字。在Flash中写入需要两个32位字对齐（地址以0x…0或0x……8结束，如果我理解正确），我的策略可以概括为：从十六进制数据记录读取地址字段，如果地址是0x……4或0x……C从ADFRES-4读取FLASH中的PyviuOS 32位字。下一个32位字（如果有的话）从HealScript写入Flash循环中的这两个32位字直到六档完全被解析，但是如果我用MPLABX阅读器读取闪存，我注意到在同一地址写两次相同的字（根据我的策略，当数据记录中的地址字段开始W时）Is0x……4或0x…c）在闪存中有不同的值，这在我在验证过程中尝试读取内容时会引起例外。在一篇文章的帖子中，我读到：“如果只有4个字节，则可以用0xFFFFFFFF填充剩下的4个字节，但是如果在HEX文件中有另一个记录，那么附加数据，从地址0x…04，或0x…0C开始，会出现问题。希望链接器不会做出这样的事情。“但是我的链接器就是这样做的！我哪里错了？有没有办法强制所有十六进制数据记录到两个32位字对齐？谢谢你的任何帮助。



      以下为原文

    Hi Friesen.
 
After reading various posts on the subject I have not yet managed to make my bootloader work properly. My lack.
I repeatedly posted my help request about that without any response.
Finally someone beats a blow. Thank you for your answer.
 
I downloaded your file but I don't know why I can't open it.

I'll explain my problem hoping you can give me a suggestion.
As IV, I'm also using PIC32MM0256GPM064 on Curiosity DevBoard with MPLABX 4.05 and XC32 1.44 (free version) and I'm trying to flash my app from a u*** flash memory via bootloader.
The unified version (Boot+App) flashed by MPLABX programmer (or IPE) works fine: it correctly jumps from Boot to App: not the same when I try to flash the App from u*** flashmem via bootloader.
The problems arise when, after writing, I execute a verify; an exception (data bus error) occurs when I try to read always the same address that ends by 0x....4.
 
Since:
- data records of the hexfile generated by linker can be up to 4 32bitWords long,
- some data record begin with the address field equal to 0x......4 or 0x......C
- the device requires writing two 32bitWord at a time
- writing in flash requires two 32bitWords alignment (addresses ending with 0x...0 or 0x...8, if I understood correctly)
my strategy can be summarized as follow:

    read address field from hex data record
    if address is 0x......4 or 0x......C
        read the previuos 32bitWord from flash at address-4
    else
        read next 32bitWord (if any) from hexrecord
    write this two 32bitWords in flash
   loop until hexfile completely parsed
 
But if I read the flash with MPLABX reader I note that writing twice THE SAME WORD AT THE SAME ADDRESS (according to my strategy this happens when the address field in data record starts with 0x......4 or 0x......c) results in a different value in flash and this causes an exception when I try to read the contents during verify.
 
In a post on the topic I read:
"If there is only 4 bytes, you may pad the remaining 4 bytes with 0xFFFFFFFF
But if there is another record in the hex file with additional data, starting with address 0x...04, or 0x...0C,
there will be a problem. Hopefully, the linker will not make something like that."
But my linker does exactly that!
 
Where I'm wrong?
Is there a way to force ALL hex data record to two-32bitWord alignment?
 
Thank you in advance for any help.
 
Albert.
 
 

嗨，Friesen，我道歉。我打开了你的文件。匆忙演奏恶作剧。-我会尽快看一看。非常感谢。艾伯特



      以下为原文

    Hi Friesen.
 
I apologize. I opened your file. Hurry plays bad jokes. :-/
I'll take a look at it as soon as possible.
Thank you so much.
 
Albert

你知道ECC和它是如何工作的吗？你确定你没有收到ECC陷阱，我记不起正确的陷阱名称了。



      以下为原文

    Are you aware of ecc and how it works? Are you sure you aren't getting an ecc trap, I can't remember the correct trap name.

是的，这似乎是个问题。我看了PIC数据表上的报道。在某些地方，我也读到，不像MZ，这个特性不能被禁用。



      以下为原文

    Yes, it seem a problem of that kind.
I read what was reported on PIC data sheet. And somewhere I have also read that, unlike MZ, this feature can't be disabled.

这两个点是，你不能重新编程以前作为0xFF的ECC块，而你必须总是编程一个完整的块。陷阱总是在读的时候发生。



      以下为原文

    The two points are that you cannot reprogram an ecc block that was previously left as 0xFF, and you have to always program a complete block. The trap always happens on reads.