BFSWIT位改变以匹配当前的BF映射？

你好QQRIS，将CSEQ:TSEQ模式写入BFXSEQ3（NoTbfxSeq0）。这应该可以解决您的问题。（数据表错误地指定了BFxSEQx和ABFxSEQx的名称，因为实际启动闪存序列单词参与了在任何代码执行之前的内置重置逻辑：它是BFxSEQ3和ABFxSEQ3，而不是BFxSEQ0和ABFxSEQ0。）启动闪存序列单词的重要性（通过删除包含在其中的闪存页面的页面，这是惟一的选项——没有四字“.”擦除），当使用新的引导加载程序。通常，在验证新引导加载程序已正确地闪烁之后，您将最后写入引导闪烁序列号。当我用复数形式讨论它们时，我的意思是主引导闪存序列词和备用引导闪存序列词（也假设启用了ECC）。交替单词（字母A指定为单词名称中的第一个字母）。在设备启动期间，读取主要单词，如果发现不可纠正的ECC错误，则设置BCFGERR(RCON<27>)标志并使用备用单词。如果在主词和备用词中发现不可纠正的ECC错误，则设置BCFGFAIL(RCON<26>)标志并使用默认配置。如果不遵循“擦除优先，写入最后”规则，请记住，如果要重置（或任何重置）在您有机会完全擦除/写入/验证新引导加载程序到上部引导别名之前都已经经历了。

嗨，肯，非常感谢你的信息，救了我几个星期的沮丧。BFx的改变正在进行中，并且它确实起到了作用：）现在我只需要弄清楚为什么第二个映像不能运行：（最佳考虑QCCurrent状态：诅咒HW在这个设计中没有包括串行。ESS真冰可以做到这一点吗？有没有办法将调试版本保存为十六进制文件？

您不需要调试第二个引导映像。只要读回，看看程序是否正确。如果它不运行，那么你所写的和原始的引导映像之间必须有差异。注意，主程序内存不受交换的影响。

嗨，qChris，如果NorthGuy的建议不能说明你的问题，有一些事情可以排除，这似乎是显而易见的，但我会列出来，无论如何，本着努力帮助的精神，因为你非常接近于成功的引导加载器！1)关于您的新引导加载程序映像，您正在尝试闪存并切换到：是否已编译了新引导加载程序，使其将用完下引导别名？如果是这种情况，十六进制文件将只包含下引导别名地址范围内的地址，即使引导加载程序本身将十六进制文件实际数据编程到上引导别名区域。我不知道您是如何设计引导加载程序和主机传输机制的，但是需要有人确切地知道在哪里对新引导加载程序进行编程。主机将把下引导别名地址从十六进制文件转换为上引导别名地址，引导加载程序对数据进行编程而无需任何地址转换，或者引导加载程序被硬编码以将接收到的数据编程为上引导别名（简单地址转换）。您要闪存和交换的新引导加载程序十六进制文件包含所需的配置字，以允许其正确运行，对吗？正如NorthGuy所建议的，您已经通过验证例程、校验和或CRC验证了整个引导加载程序（以及配置空间）的编程是否正确？我们很难从您的帖子中看出您从您的有利位置看到的内容，即告诉您新的引导加载程序实际上没有运行？听起来你很亲近。如果你还滞留，请随时通知我们，并提供更多的细节。最好的问候，肯。

嗨，qChris，您可能已经这样设计过引导加载程序，但是对于您来说，在编程之前，您已经有足够的RAM在本地存储整个80KB的引导映像。如果引导加载器在从主机接收的映像中有一个校验和，您甚至可以一次验证它，如果它是一个损坏映像，甚至不尝试对其进行编程（只要向主机回踢错误代码即可）。使用这种技术，主机不需要向引导加载程序提供关于在何处编程新引导加载程序映像的任何地址信息。活动运行的引导加载程序将只对整个80KB进行编程（但如果您在验证新引导加载程序被正确地写入闪存之后最后才对引导闪存序列号进行编程，则不会采用线性方式），RAM映像将被写入非活动上部，如本线程中先前所讨论的引导别名。许多方法来蒙皮猫-总是权衡和优点/缺点/简单/复杂性。最好的问候，肯

首先，谢谢你们的回复和支持，我真的很感激。xc32-bin2hex确实从调试elf映像生成一个.hex文件，但它看起来像mplabx，或者icd3在编程期间动态地修改它。有时我会回到这个话题。这是我的内存比较代码，它比较BF 1&2，然后PF 1&2:N.B。我已经替换了'!'对于这些论坛似乎不喜欢的百分比符号！！！！！！！在测试中，我创建了一个..hex，带有引导加载程序重置和移除PFSWAP，允许通过icd3编程的图像继续运行。我通过ICD3用这个图像编程PIC并使用相同的.HEX文件运行Bootloader进程。我的内存比较代码报告只有BFxSEQ位置不同。此时BF1和BF2包含相同的代码，PF1和PF2也是相同的。在我看来，无论是哪一个BF都在运行，也不应该运行哪个PF，有些东西应该运行。但是，在软复位或电源复位后，我没有从USB或网络端口得到任何通信。我想有一个外围问题我需要处理……但是电源循环可以处理这个问题。------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ents除了配置设置@1fc4ff00和1fc6ff00之外没有其他用途。其思想是保持BFn和PFn同步，BF1总是用PF1执行，BF2总是用PF2执行，引导加载程序总是更新当前未使用的BF+PF对。--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------我会发布我的当前地址映射代码，它可能不完整，但是内存比较表明它是足够的，尽管我的麻烦另有说明；

我的头仍然撞在硅墙上。我已经开始尽可能地从BF移动到PF（c-startup等），结果PF主映像和引导映像似乎工作得很好，包括在这些相同的映像之间进行实时切换。我开始认为它只是一个配置。定量问题，或者EEC，或者一些神秘的检查。在引导加载之后配置区域，但是在重置之前，它在重置之后永远不会返回。

如果你的BF和PF都相同，那么就不应该考虑如何交换。PF有点复杂，因为编译器可能在两个PF中都生成了一些代码，所以如果你将一个PF复制到另一个PF，它会覆盖另一个PF中的代码。你检查过了吗？

感谢@的指针，我现在保持图像相同，并且我已经尝试了几种方法来识别BF和PF对之间的任何差异……即使当设备正在运行发布代码时，icd3也可以从连接的设备中提取完整的内存映像，因此这很简洁：）在“执行内存”->；“输出到文件”选项（1）中看起来有几个bug，但是工具栏“读取设备内存到文件”工作得很好。“结束地址”有时是（？）忽略了，在使用这个函数之后，在“Read Device Memory Main Project”------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------S运行到完成，但有些事情挂起/失败/“例外”之前，呼吁调用。用于主映像和引导集映像的代码相同，“.startup”映射到链接器文件中的PF。

你好QQRISS，1）如果有异常，你是否有一个异常处理程序和任何端口引脚或发光二极管？（我想您之前说过没有为“printf”调试分配引脚。）2）引导加载程序代码是使用标准还是使用定制的C运行时？3）您的应用程序代码使用标准还是定制的C运行时？4）从运行的应用程序转换为引导加载程序的机制和步骤是什么？最好的问候，肯

嗨，克里斯，最终由你来决定，不过也许你可以暂时分叉你的代码，只专注于让双引导功能工作？换言之，忘记双PFM面板，将应用程序视为单个PFM映像（两个PFM面板的组合）。然后只需在双引导引导下完成，只需一个PFM图像就可以引导Bootloader的字段升级。在双引导工作之后，您可以返回并阶段对双PFM面板进行实时更新。现在，似乎有更多的调试复杂性，因为您试图使PFM的双引导和实时更新同时工作。也许分裂和征服会更简单？但是，这将涉及工作分心和代码分叉，谁知道呢，最终可能比继续调试当前课程花费的时间更长。我只是抛出一个想法，这可能只是一个简单的坏建议。（最好的问候，肯）

它的工作原理是：啊，我的克隆函数导致了一个完全可交换的系统对…一周以来的第一次进步。谢谢你们的建议和帮助我保持理智。我仍然可能对第一封写给BF的四字格有问题，通过ICD3查看NVMADDR、NVMDATA0、NVMDATA1、NVMDATA2、NVMDATA3，它们包含的值与地址不一致以及我可以在NVMQuordWordDead函数中看到的数据。作为临时修复，如果NVMDATAx与存储在中间缓冲区中的值不匹配，则第二次调用第一个四元组。我正在进一步研究。ICD3不适合调试启动问题，对于真正的、好的老式ICE，甚至对于这个板上的几个LED和一个串行端口，我都会付出什么。硬件设计者要注意。无论如何，我还有工作要做，只是想分享一些成功。我将更新任何进展。

克里斯，干得好！是什么使事情从非工作变成了工作？关于四字写问题：你写的地址是什么？当您正在读取验证值时，是否来自缓存或未启动的引导闪存地址？肯

嗨，肯，第一次写的地址是0x1fc6000…但我可能有更确定的消息，当然是我的全部错误；）这里是默认nvm.c中的FlashErase擦除代码，这有点令人困惑，因为PAGE_ERASE_OPERATION代码路径是阻塞操作（1），而其他两个代码路径是非阻塞的，并且依赖于调用代码来等待r PLIB_NVM_FlashWriteCycleHasCompleted(NVM_ID_0)，当我使用UPPER_FLASH_REGION_ERASE_OPERATION代码路径时，我的克隆函数的第一个错误是省略了完成检查。上面的UpjyPay-EffeleCaseCo代码的几乎完全复制。这使我的克隆代码中的问题从“在进行UPPER_FLASH_REGION_ERASE_OPERATION的同时进行操作”转移到“在最终BF PAGE_ERASE_OPERATION正在进行时进行操作”。DE像预期的那样第一次工作。这确实使我的FlashErase函数成为阻塞调用，但这是另一天的问题。（1）对于除了最终写入之外的所有操作，阻塞操作依赖于调用者等待完成。回到测试：）

所以现在事情变得比奇怪的更奇怪了.1)我构建一个发布映像，并通过ICD3从MPlabX将它编程到pic32。根据我的gpio行调试，图片没有达到_on_reset函数----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------当然是不同的文件。将两个十六进制文件输入WinMerg，它们是相同的。------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------除了下图和上图不同的字符串之外，y是相同的。--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------IPE编程与引导程序内存映像，图片立即弹出生命，BFSWAP=1，PFSWAP=1。！！！！！！顺便说一句，要注意一件有趣的事。在这两种情况下，IPE都会产生两个验证错误：confifigurationmemoryAddress:0x1fc0fff0ExpectedValue=0xfffd0002，receivevalue=0xfffc0000ConfigurationMemoryAddress:0x1fc4fff0ExpectedValue=0xfffe0001，receivevalue=0xffffc0000。FFFFFFFF和FFFD0002FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFFFF的BF2SEQ，我们可以猜到，如果BF1SEQ无效，但是BF2SEQ有效，那么将选择图像。回到我的噩梦

如果MPLAB X读取两个文件相同，但是行为与POR不同，那么唯一的解释就是MPLAB X读取中的一个bug。MPLAB X在这里创建了一点混乱，因为将0x1fc0xxxx和0x1fc4xxxxxxx都放入从..read读取的十六进制文件中不是一个好主意。如果这样的文件被编程，那么这两个区域都被编程，并且每个引导块都被编程两次。如果不交换引导区域，这不会造成问题（除了对闪存的损坏），因为两个写入都是相同的。如果启动分区被交换，它只是重新编程两个不同的图像到两个分区。因为编程只能对1到0进行编程，但是不能返回，所以您将得到两个映像的逻辑“and”：0xfffd0002&0xfffe0001=0xfffc0000，而这正是您在两个引导分区中得到的。由于两个引导扇区都是错误的，所以第一个扇区就开始了。微芯片认为编程工具不需要分区感知（他们甚至在编程规范中说明了这一点），但这是不正确的。需要考虑分区，更糟糕的是，还没有完美的解决方案。要为我们的程序员找到一个合适的折衷方案还需要一段时间。还要注意，交换位位于NVMCON寄存器中，所以在编程flash时需要小心不要引起交换。如果您只向NVMCON写入OP代码，则可以清除两个交换位。

我对两个文件的谜团没有答案，但你是用0xFFFC000价值。希望演示代码/LIB代码尊重这个Q）是保证以升序排列数据的HEX文件吗？Q）我是否应该缓冲BF的数据并确保它被写为四字？我的克隆代码是从“开始”到“完成”的哑拷贝，所以总是使用四字写。我看到bootloader.c中的示例代码有一个路径，如果地址不在边界上，和/或要写入的其余数据长度小于16字节，则数据将作为单词写入。

上一篇文章是我在回家的路上做的。稍微多花点时间，我运行的测试就会显示出积极的结果。Q）十六进制文件保证按升序显示数据吗？A)不是。但是转到Project Properties->Building并在“Normalize hex file”选项上打勾，将后处理生成的.hex文件，并确保所有记录都是按address.Q的升序排列的）我是否应该缓冲到BF的数据，并确保它被写成四字？A）我愿意对此发表评论，但我怀疑答案是肯定的，即使只是针对配置。空间？或者可能是所有BF写的？------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------通过ICD3编程，然后加载与第二图像相同的副本…重置，并且它启动并运行，显示BF2和PF2是活动的：）----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------正如Ken在#6后面所说，有足够的RAM来缓冲完整的80k映像，但是这是一个很大的块，可以放在一边，并且尝试动态分配或禁用未使用的资源来重新使用所分配的ram听起来像是一条潜在的错误路径。我总是可以使用上位程序闪存来缓冲BF，然后在检测到第一个PF相关的十六进制记录时复制到实际的BF并擦除上位PF——当然是我能想到的最简单的解决方案。再次感谢大家：）

管理决策。基于自定义PC的软件将线性化十六进制文件数据，并确保四字分组被发布到pic。这可能为时过早，因为有很多测试要做，但是。到目前为止，bootloader.c需要进行修改，以允许访问BFBF地址转换，这取决于PLIB_NVM_BootFlashBank2IsLower.，并且应该解析为两个固定区域之一。ash区域。等效于nvm.c BL_FlashErase应该擦除BF和PF。on_reset例程是设置PFSWAP位的有用位置，它应该位于BF中并避免所有PF定位的函数调用。确保选中Normalize十六进制文件选项将至少给您一个战斗的机会通过PIC32 Bootloader应用程序在2014／02／14 AN1388应用注释中编程功能图像。我想我没有时间研究四字缓冲。ICD3工具链不适合调试这种引导加载程序实现，或者实际上不适合任何需要电源重置的进程。在PF交换之后，我已经调试了一些成功，但是VootEnter应用。验证/内存比较确保所有的数据都在正确的位置，但是如果我的使用HoX文件的引导程序和演示代码是真实的，那么必须考虑WRT是如何写数据的。同样，我认为我没有时间进一步研究。最后，BFSWIT位确实匹配当前的BFXSEQ映射。