Muny驱动程序不允许更新BFM？

我遇到的一个潜在问题是使用USAT模式中的引导加载程序并启用Web服务器。由于文件系统与此有关，所以Bootloader C在以下两个地方遇到麻烦，其中使用以下条件有条件地包含代码：SysffsMax文件（Gt；0）。此代码可能是用于USB MSD引导加载程序，但包含在我的案例中，因为除了基本检查之外没有别的。



      以下为原文

    A potential issue that I've run into is using the bootloader in USART mode and having the web server enabled. Since a file system is involved with that, bootloader.c runs into trouble in the two places where the following condition is used to conditionally include code: SYS_FS_MAX_FILES > 0. This code is probably for USB MSD bootloaders, but is included in my case because there is nothing other than that basic check.

最后一件事：有人注意到统一引导加载程序0.1.8的速度有多慢吗？也许是因为我在使用UART LIVUPEPRODE，但需要6-8分钟。



      以下为原文

    One final thing: has anyone noticed just how SLOW the Unified Bootloader Application 0.1.8 is? Maybe it's because I'm using the UART liveupdate, but it takes like 6-8 minutes.

事实上，它似乎不和谐将允许您使用USB与现场更新。有人能验证这些问题吗？



      以下为原文

    Actually it doesn't seem like Harmony will allow you to use USB with Live Update. Can anybody verify these issues?
 

我必须接受疯狂的药丸，因为我从BSP中删除了下面的一行，并且我被允许最终选择除了USAT之外的东西：



      以下为原文

    I must be taking crazy pills, as I removed the following line from BSP and I was allowed to eventually select something other than the USART:
 
set USE_BOOTLOADER to y

基于USAT LIVUPDATE Bootloader的速度（如果使用统一的Bootloader应用程序0.1.8，这里称为UBA，115200是最大值），并且我必须创建自己的应用程序或修改UBA，那么我将转到UDP LIFEUPDATE Bootloader。我认为从长远来看，这将更加灵活，而且最快（25秒左右）。然而，这并不是没有问题的。我希望Microchip的人能够对这些问题发表评论。第一个问题是Bootloader。C有以下条件代码：SysffsMax文件& Gt；0。它在两个地方，显然只适用于使用USB主机应用程序的LIVUPEDATE。由于我使用Web服务器的文件系统，即使我不使用USB，也会触发这个代码。这似乎不正确。第二个问题源于使用UDP LIVUpDead应用程序，而不是Bootloader。就目前而言，当LIFEUPDATE应用程序完成了未使用的面板的编程时，调用DATASRAMAMORACK。这是有意义的，但是为什么它会关闭整个TCPIP栈呢？？？？关闭套接字应该足够了，因为应用程序实际上没有重置自身。当然，用户可以用BooLoad Server程序完整注册器注册一个函数，并重置应用程序，但是如果用户犯了错误又想重新编程怎么办？我觉得在BooToLoad中可以有更大的灵活性。最后一个问题是UBA本身。这件事似乎只在一个模式下操作，可能与前面段落中的上述问题有关。最后，由于我继续对此问题发表文章，我想感谢Microchip提供LIFEUPDATE Bootloader切换器/应用框架。至少在这一点上，这给我们提供了一个几乎不可破解的解决方案。同时，我们将使用MPFS2应用程序进行杀戮。如果整个应用程序（包括Web应用程序）可以在不中断CPU的情况下被编程到另一个面板中，为什么我们需要这个？最好的部分是它确保客户端脚本与服务器/PIC侧CuuthHutpApp.Edvest:保持一致：显然，我们将使用MPFS2生成正确的文件，但是我们将不再需要独立于应用程序来更新网页。



      以下为原文

    Based on the speed of the USART liveupdate bootloader (115200 is the max if using the unified bootloader application 0.1.8, hereby referred to as UBA) and the fact that I'd have to either create my own application or modify the UBA, I am moving on to the UDP liveupdate bootloader. I think this will be more flexible in the long run and is most certainly faster (25 seconds or so to program). However, it is not without some issues. I'm hoping that someone from Microchip can comment on these issues.
 
The first issue is that bootloader.c has the following conditional code: SYS_FS_MAX_FILES > 0. It's in two places and apparently is only applicable to using liveupdate with USB host application. Since I use the file system with my web server, this code is triggered even if I don't use USB. This does not seem right.
 
The second issue stems from the use of the UDP liveupdate application, not the bootloader, which has been rock solid this entire time. As it currently stands, when the liveupdate application has finished programming the non-used panel, DATASTREAM_Close is called. This makes sense, but why does it shut down the entire TCPIP stack?!?! Closing the socket should suffice because the application doesn't actually reset itself. Sure the user could register a function with BOOTLOADER_ProgramCompleteRegister and have that reset the application, but what if the user made a mistake and wants to program again? I feel like there could be a little more flexibility programmed into this bootloader
 
The final issue is with the UBA itself. This thing seems only to operate in one-shot mode, probably related to the aforementioned problem in the previous paragraph.
 
Finally, since I continue to post regarding this issue, I want to thank Microchip for providing the liveupdate bootloader switcher/application framework. This has provided us, at least at this point, with a nearly unbrickable solution. At the same time, we're going to kill off using the MPFS2 application. Why would we need this if the entire application (including the web app) can be programmed into the other panel without stalling the CPU? The best part is that it ensures the client side scripting stays consistent with the server/PIC side custom_http_app.
 
EDIT: Obviously, we'll use MPFS2 to generate the correct files, but we'll no longer need to update the webpages independently from the application.

我保证这将是这个帖子上的最后一篇文章，但是请让我沉迷其中一点。我看到一些奇怪的东西，我无法解释。我有两组固件是相同的，除了一个寄存器设置为4，另一个设置为5。这些寄存器是通过串行端口访问的，这有助于我确定我正在处理的固件一瞥，LED如何操作演示应用程序。我还显示PFSWAP和BFSWAP。Bootloader（Switter）和应用程序都按照Orthon的堆栈从UDP工作。在应用程序代码中，通过BooLoad Server程序完整性注册器注册一个函数。这个函数简单地用以下逻辑关闭中断和重置：假设在某个时间点，我正在读取5，pfSWAP是1（bfSWAP每次读取0，这就是我所期望的）。这是因为活动面板包含将寄存器设置为5的固件。如果我用统一的Bootloader应用程序对设备进行编程，并且应用程序将寄存器设置为4，则重置发生，但我仍在读取5和1。如果我循环功率，那么我将读取4和0。如果我现在用将寄存器设置为5的应用程序对设备进行编程，则软件重置发生，而我读取5和1而没有电源周期。我可以用同样的结果来来回回恶心。当编程发生时，为什么PFSWIT是1，然后是0，而不是反过来呢？有什么建议吗？



      以下为原文

    I promise this will be the last post on this thread, but please indulge me for a bit. I'm seeing something strange that I can't quite account for. I have two sets of firmware that are identical except that one sets a register to 4 and the other sets it to 5. These registers are accessed via a serial port and this helps me to determine which firmware I'm dealing with at a glance, kind of how the LEDs operate for the demo applications. I also display PFSWAP and BFSWAP. Both the bootloader (switcher) and the application work off of UDP as per Harmony's stack. In the application code, a function is registered via BOOTLOADER_ProgramCompleteRegister. This function simply turns off the interrupts and resets with the following logic:
 

int APP_Bootloader_ForceResetAfterProgram(void)
{
    PLIB_INT_Disable(INT_ID_0);
    SYS_RESET_SoftwareReset();
}

 
Suppose that at some point in time, I am reading 5 and PFSWAP is 1 (BFSWAP reads 0 every time, which is what I would expect). This is because the active panel contains the firmware that sets a register to 5. If I program the device with the Unified Bootloader Application and the application setting a register to 4, the reset occurs but I'm still reading 5 and 1. If I cycle power, then I'll read 4 and 0. If I now program the device with the application that sets the register to 5, the software reset occurs and I'm reading 5 and 1 WITHOUT a power cycle. I can go back and forth ad nauseam with the same results. Why would I need a power cycle when programming occurs such that PFSWAP is 1 and then 0, but not the other way around? Any suggestions?

你好B祝福，我可能在这里偏离了目标（理解这个问题），但是也许你可以快速地为你的重置代码试试这个，看看是否有任何积极的效果：（我想知道和谐复位MCU实现是否不执行‘阻止任何不需要的代码执行，直到M。CU重置实际发生“摘录”？这是我使用的Bootloader使用的重置代码：



      以下为原文

   


Hello Bblessing,
 
I may be way off the mark here (in understanding the issue) but perhaps you could quickly try this for your reset code to see if there is any positive effect:
 
(I'm wondering if the Harmony reset MCU implementation is not performing the 'Prevent any unwanted code execution until the MCU reset actually occurs' snippet? Wild guess.)
 

int APP_Bootloader_ForceResetAfterProgram(void)
{
    //PLIB_INT_Disable(INT_ID_0);
    //SYS_RESET_SoftwareReset();
    
    uint32_t dummyRead = 0;

    // Disable interrupts
    __builtin_disable_interrupts();

    // TODO: Suspend DMA here if we ever use DMA in the future

    // The system unlock sequence must be performed before the
    // 'SWRST' bit can be written.
    SYSKEY = 0x00000000;
    SYSKEY = 0xAA996655;
    SYSKEY = 0x556699AA;

    // Prepare for the software-reset of the microcontroller
    RSWRSTSET = 1;

    // Once the 'SWRST' bit is set, any read of the 'RSWRST' register
    // will trigger the reset.
    dummyRead = RSWRST;

    // Prevent any unwanted code execution until the MCU reset actually occurs
    while(1)
    {
        dummyRead++;
    }    
}

 
 
 
This is the reset code I was using for the Bootloader I worked on:
 

static void SoftwareReset(void)
{
    uint32_t dummyRead = 0;

    // Disable interrupts
    __builtin_disable_interrupts();

    // TODO: Suspend DMA here if we ever use DMA in the future

    // The system unlock sequence must be performed before the
    // 'SWRST' bit can be written.
    SYSKEY = 0x00000000;
    SYSKEY = 0xAA996655;
    SYSKEY = 0x556699AA;

    // Prepare for the software-reset of the microcontroller
    RSWRSTSET = 1;

    // Once the 'SWRST' bit is set, any read of the 'RSWRST' register
    // will trigger the reset.
    dummyRead = RSWRST;

    // Prevent any unwanted code execution until the MCU reset actually occurs
    while(1)
    {
        dummyRead++;
    }
}

 
 

肯，谢谢你的回复！我试一试，但问题依然存在。这是非常奇怪的：如果PFSWAP是0，我通过UBA 0.1.8应用程序对另一个面板编程，设备重置和PFSWAP显示为1。如果我再次这样做，重置发生，但PFSWAP仍然是1。但是，如果我在任何时候循环功率，PFSWAP会反映出我所期望的值。查看参考手册中的重置效果（第52节，Live Update），我看到了这个小插曲：这似乎是一个领先。我最终想要完成的是，在设备被编程之后，它复位，从而允许用户使用新固件。用户可能不总是能够物理地循环功率，因为如果使用UDP，UDP将允许用户从其办公室的舒适性更新设备，而不是热的、脏的和嘈杂的热处理设施。就目前而言，只有当pFSWIT是0到1，而不是1到0时，这才是有效的。我认为在引导装载器中是否应该交换面板的最初决定是我应该看的地方。



      以下为原文

    Ken,
 
    Thanks for the reply! I gave it a shot, but the problem remains. It's just very strange: if PFSWAP is 0 and I program the other panel through the UBA 0.1.8 application, the device resets and PFSWAP shows as 1. If I do this again, the reset occurs, but PFSWAP is still 1. HOWEVER, if I cycle power at any point, PFSWAP will reflect the value that I would expect.
 
    Looking at the effects of a reset in the reference manual (section 52, live update), I see this tidbit:
 

 
    This seems like a lead. What I'm ultimately trying to accomplish is that after the device is programmed it resets, thus allowing the user to work with the new firmware. The user may not always be able to physically cycle power, as using UDP will allow the user to update a device, if need be, from the comfort of their office, as opposed to a hot, dirty, and noisy heat treating facility.
 
    As it currently stands, this only works when PFSWAP is 0 going to 1, not 1 going to 0. I think the initial decision in the bootloader as to whether the panels should be swapped is where I should look.
 

我想Microchip需要看看这个。尽管我已经找到了解决问题的方法，但我认为它是一个相当蹩脚的解决方案，因为它违反了LIFEUPDATE引用中的注释（关于PFSWAP位）：我的代码修复这个问题是：我现在可以使用软件重置和任何我更新代码的时间，重置发生，和面板交换正确地发生。不过，我不喜欢这样的事实，我正在更新PFSWIT位从PFM。我也在努力理解为什么会这样。必须有一些从软件复位中坚持下来的东西，在启动引导程序中与面板交换。在Microchip提供的所有示例应用程序中，假设要进入最近编程的面板，必须发生电源循环。不幸的是，我们中的许多人需要能够触发软件重置以便看到更新的固件。



      以下为原文

    I think Microchip needs to take a look at this. Even though I've found a solution to my problem, I believe it to be a pretty crappy fix because it violates a comment in the liveupdate reference (regarding the PFSWAP bit):
 
 
 
My code to fix the issue is this:
 
int APP_Bootloader_ForceResetAfterProgram(void)
{
    PLIB_INT_Disable(INT_ID_0);
    PLIB_NVM_MemoryModifyInhibit(NVM_ID_0);
    PLIB_NVM_MemoryOperationSelect(NVM_ID_0,NO_OPERATION);
    PLIB_NVM_FlashSwapLockSelect(NVM_ID_0,NVM_FLASH_SWAP_UNLOCKED);
    if (NVMCONbits.PFSWAP)
    {
        PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY1);
        PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY2);
        PLIB_NVM_ProgramFlashBank1LowerRegion(NVM_ID_0);
    }
    SYS_RESET_SoftwareReset();
    while (1);
}
 
I can now use software resets and any time that I update the code, the reset occurs, and the panel swap occurs correctly. Still, I don't like the fact that I'm updating the PFSWAP bit from the PFM. I'm also trying to understand exactly WHY this works. There has to be something that is persisting from a software reset that screws with the panel swapping on startup in the bootloader.
 
The example applications that Microchip provides all operate under the assumption that to get to the most recently programmed panel, a power cycle must occur. Unfortunately, many of us need to be able to trigger software resets in order to see the updated firmware.

这根本没有任何意义。我的理解是PFSWAP在任何情况下都无法重置。也就是说，它的电量将达到0。我可能不得不再次发布疯狂药丸GIF，因为它看起来好像可以加1，或者有一些东西我根本不明白。我最后编辑了Bootloader。C，因为我不喜欢上面的修复，最终决定应该使用哪个面板应该在Bootloader中。在引导加载程序进入Enter应用程序时，PFSWAP实际上可能是1，我改变了SavaFlash面板和SurvivApple应用程序功能。基本上，我使用PLIPBIN NVMY程序FLASBANK1LUVER区域、PLIPYNVMY程序Flash BANK2LUVER区域，以及PLBIZNVMY程序Flash BANK2ISLeLeRead区域，除了Flash ID更大之外，来决定如何交换面板。我的代码在下面。这似乎可行。如果软件重置后PFSWAP确实可以是1，有人可以参考闪存部分的52.17，并向我解释我遗漏了什么吗？在读取之后，PFSWAP似乎总是在任何重置之后重置。



      以下为原文

    This doesn't make any sense at all. It was my understanding that PFSWAP DID NOT SURVIVE A RESET UNDER ANY CIRCUMSTANCES. That is, it would power up as 0. I may have to post the crazy pills gif again because it seems like it can power up as 1, or there is something I simply don't understand.
 
I ended up editing bootloader.c, since I didn't like the fix above and the ultimate decision as to what panel should be used belongs in the bootloader. Armed with the possibility that PFSWAP could actually be 1 by the time the bootloader enters EnterApplication, I changed the SwapFlashPanels and EnterApplication functions. Basically I use PLIB_NVM_ProgramFlashBank1LowerRegion, PLIB_NVM_ProgramFlashBank2LowerRegion, and PLIB_NVM_ProgramFlashBank2IsLowerRegion, in addition to which flash id is larger, to make the decision as to how to swap the panels. My code is below. This seems to work.
 
If PFSWAP can indeed be 1 after a software reset, could someone please reference section 52.17 of the flash memory section and explain to me what I'm missing? It really seems, after reading, that PFSWAP is ALWAYS reset after any reset.
 

#if(BOOTLOADER_LIVE_UPDATE_SWITCHER == 1)
/********************************************************************
* Function:     SwapFlashPanels()
*
* Precondition:
*
* Input:        Boolean indicating whether the switch should go to panel 2
*
* Output:
*
* Side Effects:
*
* Overview:     The function will swap the flash panels in a safe
 *              place.
*
*
* Note:         This is placed in the .cache_init section in order
 *              to have it in boot flash rather than program flash.
********************************************************************/
void __longcall__ __attribute__ ((section (".cache_init"))) SwapFlashPanels(bool panel2)
{
    PLIB_NVM_MemoryModifyInhibit(NVM_ID_0);
    PLIB_NVM_MemoryOperationSelect(NVM_ID_0,NO_OPERATION);
    PLIB_NVM_FlashSwapLockSelect(NVM_ID_0,NVM_FLASH_SWAP_UNLOCKED);
    PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY1);
    PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY2);
    if (panel2)
    {
        PLIB_NVM_ProgramFlashBank2LowerRegion(NVM_ID_0);
    }
    else
    {
        PLIB_NVM_ProgramFlashBank1LowerRegion(NVM_ID_0);
    }
}
#endif

#if(BOOTLOADER_LIVE_UPDATE_STATE_SAVE != 1)
/********************************************************************
* Function:     Enter_Application()
*
* Precondition:
*
* Input:        None.
*
* Output:
*
* Side Effects: No return from here.
*
* Overview:     The function will program the checksum for the respective
 *              flash panel and jumps to application programmed in it.
*
*
* Note:
********************************************************************/
static void Enter_Application(void)
{
    void (*fptr)(void);

    /* Set default to APP_RESET_ADDRESS */
    fptr = (void (*)(void))APP_RESET_ADDRESS;

#if(BOOTLOADER_LIVE_UPDATE_SWITCHER == 1)
    T_FLASH_ID *lower_flash_id = LOWER_FLASH_ID_READ;
    T_FLASH_ID *upper_flash_id = UPPER_FLASH_ID_READ;

    SYS_DEVCON_InstructionCacheFlush();

    /* Application has been programmed first time into flash panel 1 by the bootloader */
    if( *(uint32_t *)LOWER_FLASH_ID_READ == FLASH_ID_CHECKSUM_CLR &&
        *(uint32_t *)UPPER_FLASH_ID_READ == FLASH_ID_CHECKSUM_CLR)
    {
        /* Program Checksum and initial ID's for both panels*/
        T_FLASH_ID low_flash_id = { 0 };
        T_FLASH_ID up_flash_id = { 0 };
 
        low_flash_id.flash_id = 1;
        low_flash_id.checksum_start = FLASH_ID_CHECKSUM_START;
        low_flash_id.checksum_end = FLASH_ID_CHECKSUM_END;

        up_flash_id.flash_id = 0;
        up_flash_id.checksum_start = FLASH_ID_CHECKSUM_START;
        up_flash_id.checksum_end = FLASH_ID_CHECKSUM_END;
        
        APP_NVMQuadWordWrite((void *)LOWER_FLASH_ID_BASE_ADDRESS, (uint32_t *)&low_flash_id);
        APP_NVMQuadWordWrite((void *)UPPER_FLASH_ID_BASE_ADDRESS, (uint32_t *)&up_flash_id);
    }
    /* If both the panels have proper checksum*/
    else if((lower_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (lower_flash_id->checksum_end == FLASH_ID_CHECKSUM_END) &&
            (upper_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (upper_flash_id->checksum_end == FLASH_ID_CHECKSUM_END))
    {
        if (upper_flash_id->flash_id > lower_flash_id->flash_id)
            SwapFlashPanels(!PLIB_NVM_ProgramFlashBank2IsLowerRegion(NVM_ID_0));
    }
    /* Fallback Cases when either of Panels checksum is corrupted*/
    else if((upper_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (upper_flash_id->checksum_end == FLASH_ID_CHECKSUM_END))
    {
        SwapFlashPanels(true);
    }
    /* Fallback Cases when either of Panels checksum is corrupted*/
    else if((lower_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (lower_flash_id->checksum_end == FLASH_ID_CHECKSUM_END))
    {
        SwapFlashPanels(false);
    }
#endif // BOOTLOADER_LIVE_UPDATE_SWITCHER == 1
    /* Disable Global Interrupts and Jump to Application*/
    PLIB_INT_Disable(INT_ID_0);
    if (bootloaderData.StartAppFunc != NULL)
        bootloaderData.StartAppFunc();
    fptr();
}
#endif // BOOTLOADER_LIVE_UPDATE_STATE_SAVE != 1

您好B祝福，对于PIC32 MZ2048 EFH100部分，您使用的数据表DS600 01320修订版D，第100页表明：包含“pSWAP”和“BFSWAP”的NYBLE将包含一个未知的重置值（所有重置）。（我的直觉是，这可能是文档错误。我预计这将是在POR（电源复位）的情况下。我希望“pSWIFT”和“bFSWAP”值在ApOR之外仍然存在“重置”。我认为这是一个你可能不得不忽略文档的情况（现在），并在实际的硅上运行一些测试用例，看看它是如何运行的。重要的是：如果你运行了一些测试，就要确保你能成功。将“pWSWAP”写入到它（解锁后），以确保它实际上改变为你所期望的——你不想被愚弄，认为如果发生了变化，如果它是锁定的并且是不可改变的。关于“52.17种不同重置的效果”（第52节）。“支持实时更新的闪存，DS600 01193修订版B页32”：我对此部分的解释是：（不幸的是，与数据表冲突）：1）“pWSWAP”是POR（POWER ON RESET）的“0”。2）“PSWAP”除了PoR之外，在任何重置都保持其预设状态。SouthalAdvices）将通过参考手册信息来了解数据表的准确性。这不是一个借口，但是，两者都应该是明确的，完全匹配，所以没有客户混淆。Bblessing，我认为这不是一个坏主意，打开一个芯片支持票，以便这可以清除/纠正责任方。数据表和参考手册之间的文档不应该像现在一样模糊不清。除了重置状态之外，最终参考手册提示启动闪存代码具有ONU来配置“PSWAP”到期望/预期状态：第52节。支持实时更新的闪存，DS600 01193修订版B-页19：“建议该位仅由BFM区域执行的代码改变。”在活动引导闪存中执行的代码是否有算法/策略回归旧的应用固件映像。如果新的应用程序固件映像（您要运行的映像）不是有效的映像（即，损坏的）？我还没有实现实时更新（只有双引导），但似乎在启动闪存代码中“降压”以验证新的（期望运行的）应用固件映像，以确定是否配置“PWSWAP”从新的应用固件映像运行或回落并运行OLDRAPP。如果认为新的应用固件映像不是“可运行”的，则使用固件映像。这是最后一次捕捉和防止错误的机会。因此，在这个意义上，“pSWAP”的重置值是不重要的，因为启动闪存代码总是会在跳到应用程序空间之前明确地将其配置为“0”或“1”。我希望这篇文章有点帮助。最好的问候，KenP。在实践中，AVE没有实现实时更新（只有双引导）项目，所以在我的建议中，我可能偏离了基础。这些只是我想通过你试图帮助你的一些想法。



      以下为原文

    Hello Bblessing,
 

 
For the PIC32MZ2048EFH100 part you are using Data Sheet DS60001320 revision D, page 100 indicates:
That the nybble that contains 'PWSWAP' and 'BFSWAP' will contain an unknown value on reset (all resets).
 
(My gut feeling is perhaps this could be a documentation mistake. I would expect that this would be the case only on a POR (Power-On Reset). I would expect the 'PWSWAP' and 'BFSWAP' values to persist anyreset except a POR.)
 
I think this is a case in which you might have to ignore the documentation (for now) and run some test cases on the actual silicon to see how it behaves.
 
IMPORTANT: If you run some tests, just make sure that you you verify the 'PWSWAP' after you write to it (after unlocking) to ensure it actually changed to what you expect it to be -- you don't want to get fooled in thinking the change occurred in the case if it is locked and is not changeable.
 



Regarding '52.17 EFFECTS OF VARIOUS RESETS' (Section 52. Flash Memory with Support for Live Update, DS60001193 revision B-page 32):
 
My interpretation of this section is this (which unfortunately conflicts with the Data Sheet):
1) 'PWSWAP' is '0' for a POR (Power-On Reset).
2) 'PWSWAP' persists its preset state on any reset except a POR.
 
My advice (that I personally follow) would be to learn towards the veracity of the Data Sheet over the Reference Manual information. This is not an excuse, however, both should be crystal clear and exactly match so there is no customer confusion.
 
Bblessing, I think it would not be a bad idea to open up a Microchip Support ticket so that this can be cleared up/rectified by the responsible parties. The documentation between the Data Sheet and the Reference Manual should not be ambiguous like it currently is.
 
Reset state aside, ultimately the Reference Manual hints at the Boot Flash Memory code having the onus to configure the 'PWSWAP' to the desired/intended state:  
 
Section 52. Flash Memory with Support for Live Update, DS60001193 revision B-page 19:
"It is recommended that this bit is only changed by the code executing from the BFM region."
 
 
Does your code executing in the active Boot Flash Memory have a algorithm/strategy to regress to the older Application firmware image if the new Application firmware image (the one you want to run) is not a valid image (i.e., corrupted)?
 
I have not implemented Live Update (only Dual Boot) but it seems the "buck stops" at the Boot Flash Memory code to validate the new (desired to run) Application firmware image to determine whether to configure 'PWSWAP' to run from the new Application firmware image or fall back and run the older Application firmware image if it is deemed that the new Application firmware image is not "runnable". It's the final chance to catch and prevent a mishap.
 
So in this sense the reset value of 'PWSWAP' is immaterial because Boot Flash Memory code will always explicitly configure it to a '0' or a '1' before jumping to the Application space.
 
I hope this post helps somewhat.
 
Best regards,
 
Ken
 
P.S. Again, I have not implemented a Live Update (only Dual Boot) project in practice so I may be off base here in my advice. These are just some ideas I wanted to run past you to try to help you out.

B祝福，有趣的是，与PIC32 MZ（EF）家族不同，较新的PIC32 MZ图形（DA）家族在其数据表（DS600 01361修订版F，第112页）中表示，“pWSWAP”和“BFSWAP”位将在所有重置（POR包含）上为“0”。OBY POST站在坚实的基础上，打开一个微芯片支持票仍然是一个坏主意，以便PIC32 MZ EF家庭数据表可以被有关方固定，如果它确实包含不正确的信息在这方面。最好的问候，肯。



      以下为原文

    Bblessing,
 
It is interesting to note that, unlike the PIC32MZ (EF) Family, the newer PIC32MZ Graphics (DA) Family indicates in its Data Sheet (DS60001361 revision F, page 112) that the 'PWSWAP' and 'BFSWAP' bit will be '0' on all resets (POR-inclusive).
 
Again, the reset value is immaterial if my previous post stands on solid ground.
 
It still would not be a bad idea to open up a Microchip Support ticket so that the PIC32MZ EF Family Data Sheet can be fixed by the responsible parties if it is indeed contains incorrect information in this regard.
 
Best regards,
 
Ken
 

肯，我对你的细致入微的回答真是感激不尽！我错过了有关数据表，我一定会打开一张票。您可以从任何时候查看我正在工作的代码，因为它是使用UDP的Hyg 2.05的股票LIFEUPDATE驱动程序。它从不查看PFSWAP位，而是比较高闪存和低闪存“ID”：每个面板在成功编程后都将其ID增加两倍。至于我的设置，我有一个DeSwitter，强制引导程序从应用程序和引导加载程序中。这样，如果所有东西都粘起来了，用户可以翻转开关，回到引导装载器。如果应用程序被注入，则可能需要一个电源周期，但仍有可能跳回引导加载程序。这部分工作完美无瑕，我还没有粉饰我的董事会。我看到的问题如下：假设我从真正的ICE编程引导引导程序。如果我通过Bootloader编程设备，面板1被编程，并且设备从面板1中耗尽。再次编程该设备，并且编程发生在面板2中。重置设备使设备从面板2中用完。如果我现在把这个程序编程第三次，程序就出现在面板1中。但是，如果我重置设备，它仍然会耗尽面板2。我要注意的是，在前一段中，所有重置都是应用程序代码中的软件重置。如果我在每一个编程步骤之后执行一个功率循环，那么设备每次都会成功地启动到正确的固件和面板，至少从我的观察中。在软件重置和实际功率周期之间有一些差异，引导器，它和谐地执行“切换”操作，似乎不起作用。这是非常奇怪的，因为微芯片的代码简单，逻辑是健全的。我想我明天会有一个更深的跳水，一个全新的想法。再一次，我对你的帮助表示感谢！



      以下为原文

    Ken,
 
    I can't thank you enough for your nuanced replies! I missed that regarding the datasheet, and I'll definitely open a ticket.
 
    You can review the code I'm working from any time, as it's Harmony 2.05's stock liveupdate driver using UDP. It never looks at the PFSWAP bit, but compares the high and low flash "ID": each panel has it's ID incremented by two after successful programming.
    As for my setup, I have a dispswitch that forces the bootloader from both the application and within the bootloader. This way if everything gets gummed up, the user can flip the switch and get back to the bootloader. If the application is hosed, a power cycle may be necessary, but it's still possible to hop back to the bootloader. This part has worked flawlessly and I've yet to brick my board.
    The problem that I'm seeing is the following: suppose I program the bootloader from my Real ICE. If I then program the device through the bootloader, panel 1 is programmed and the device is running out of panel 1. Program the device again, and the programming occurs in panel 2. Resetting the device gets the device to run out of panel 2. If I now I program the device a third time, the programming occurs in panel 1. However, if I reset the device, it will still run out of panel 2.
    I should note for the previous paragraph, all resets are software resets in the application code. IF I perform a power cycle after each programming step, the device boots up to the correct firmware and panel every time without fail, at least from my observation. There is just some difference between the software resets and actual power cycles that the bootloader, which, in Harmony, does perform the "switching" operation, doesn't seem to account for. It's very bizarre, as Microchip's code is simple and the logic is sound. I think I'll do a bit of a deeper dive tomorrow with a fresh mind.
    Again, I can't thank you enough for your help!

你好，B祝福。非常欢迎你。知道根源是肯定的。当你能够克服这个问题时，你会感到兴奋！当我能看到任何红色标志弹出时，我会尽我所能仔细地看代码。我的时间有点零碎了，干得不错！你有一个很好的恢复计划。除了一些编码的疏忽还没有发现：我在这里掌握了一些线索，但是我想知道这是否是一个数据或指令缓存一致性问题，它本身就是你所看到的行为。把问题扔到外面去解决是值得的。我不确定尝试最简单最快的方法是关闭数据和指令缓存，看看这是否有积极的效果。您必须强制从未清除的KSGE1地址区域的所有数据/指令访问。我不是MIPS专家（已经有一段时间了，我最近和ARM核心一起工作），也许论坛社区的人可以帮忙。我必须自己研究一下——我相信这可以在函数的基础上用XC32属性来完成，但是这可能在链接脚本本身中做得更容易和全局。或者可能在C启动代码中？可能只是简单地将缓存策略更改为“uncache”（实际上我没有这样做，所以我必须研究这个）。再次，这将是一个暂时的修改作为一个实验（作为一个目标，看看这是否是一个缓存一致性的问题，或者它可能会导致一个不同的根本原因）。Bblessing，继续挖掘，并让我们张贴在你的发现。到目前为止，你做得很好——你非常亲近！最好的问候，肯



      以下为原文

     
Hello Bblessing.
 
You are very welcome. It sure will be nice to know what the root cause is. It will be a thrill for you when you are able to overcome this issue! I'll try my best to look at the code a bit more in detail when I am able to see if any red flags pop up. My time is kind of fragmented right now.
 

 
Nice job! You have a nice recovery plan there.
 

 
Beyond some coding oversight that has not been found yet:
 
I'm grasping for straws a bit here but I am wondering if this might be a Data- or Instruction-cache coherency issue that is manifesting itself as the behavior you are seeing. It's worth throwing the question out there to rule it out. I'm not sure what the easiest/quickest way would be to try an experiment to turn off the Data and Instruction caches to see if this has a positive effect or not. You would have to force all data/instruction accesses from uncached KSEG1 address regions. I'm not a MIPS expert (it's been a while and I'm working with an ARM core lately) so maybe someone in the Forum Community can help out. I'd have to research this myself a bit -- I believe this can be done with XC32 attributes on a function basis but maybe this could be done easier and globally in the linker script itself. Or perhaps in the C startup code? It might be that you simply just have to change the cache policy to 'uncached' (I have not done this in practice so I would have to research this). Again, this would be a temporary modification as an experiment (as a goal to see if this is a cache coherency issue or perhaps it would lead to the a different root cause).
 
Bblessing, keep digging in and keep us posted on your findings. You've done a great job thus far -- you are very close!
 
Best regards,
 
Ken

另一个线程中的论坛成员发布了我在此发布的链接。完全禁用CaseHTTP://MyCHIPPrdult.COM/32位：MZ Cache Dabable。这应该是最简单的方法来禁用数据和指令缓存，以查看是否存在缓存一致性问题。请注意。我并不是暗示这是原因或解决方案——只是一个调试实验数据点，有助于确定实际的根本原因，以便能够应用适当的修复。



      以下为原文

    A Forum Member in another thread posted this link which I am re-posting here. 
 
Completely disable cache
http://microchipdeveloper.com/32bit:mz-cache-disable
 
This should be the easiest way to disable the Data and Instruction caches completely to see if you might have a cache coherency issue.
 
Please note I am not implying that this is the cause or the solution -- just a debugging experimental data point that may help to identify the actual root cause so that a proper fix can be applied.
 

所以这可能会带来更多的问题而不是答案。我完全能够证明PFSWAP有时会以1的速度启动。肯的数据表指出PFSWIT的初始值是未定义的，这让我想到了我的方法。与MZ DA芯片相匹配，保证启动时PFSWAP为0，我认为最好在启动时强制PFSWATE为0。无论如何，为了证明，我把这个代码放在AppIn初始化中：这个代码将在SysSyrimalItdit中执行，并且将在对BooLoad Services任务的任何调用之前发生，其中包含调用EntLyApvest:唯一调用SWAPFlash面板的函数，因此调用PLIPYNVMY程序Flash BANK2LUVER区域的唯一函数。这就提出了以下问题：如果在启动时PFSWAP是1，那么对SynLead应用程序中的以下代码段会有什么影响：宏扩展到这个（LoeReFaseIdBaseBaseAddio= 0x9D900My）：在EngIn应用程序中交换面板的决定基于以下内容：我们可以合作吗？但是，假设PFSWAP的状态，在这两种情况下，LoeLer-Flash ID和UpPurFlash ID都是从同一点读取的？我不知道我们可以，但我也不是一个关于虚拟到物理宏的专家。如果这带来了问题，那么修复很简单：交换面板，使PFSWIT为0，因为它将在一个电源周期。这个解决方案的优点是：如果它不是问题，那么代码将永远不会被执行，如果它是，那么我们知道PFSWAP将在正确的状态之前，任何闪存面板操作。因此，在EngILL应用程序中，微芯片的面板切换逻辑，只要使用一个电源周期就可以很好地工作，它具有正确的逻辑，不需要修改。这是我在没有问题的情况下开始使用的；我上面的尝试并没有起作用（正如我今天早上发现的），因为我认为PFSWAP在启动螺钉上设置了Flash ID逻辑。我修改了SavaFlash面板函数（类似于前一篇文章），Studio应用程序（以反映SavaFlash面板现在采取布尔参数），并且BooDouthRoLi初始化（现在包含一个简单的if语句，如果PFSWAP是1，交换面板）。再次感谢肯！



      以下为原文

    So this will probably add more questions than answers, but here goes. I have been absolutely able to prove that some times PFSWAP will start up as 1. Ken's point about the datasheet stating that the initial value for PFSWAP being undefined got me thinking about my approach. Couple that with the MZ DA chips guaranteeing that PFSWAP is 0 at startup, I figured it would be better to FORCE PFSWAP to 0 on startup.
 
Anyway, for proof, I put this code in APP_Initialize:
 

if (PLIB_NVM_ProgramFlashBank2IsLowerRegion(NVM_ID_0))
    while (1);

 
This code will execute in SYS_Initialize and will occur before any calls to Bootloader_Tasks, which contains a call to Enter_Application: the only function that calls SwapFlashPanels, and thus the only function that calls PLIB_NVM_ProgramFlashBank2LowerRegion.
 
Sure enough the program would lock up in the while loop. This raises the following question: if PFSWAP is 1 at startup, what does this do to the following section of code in Enter_Application:
 

T_FLASH_ID *lower_flash_id = LOWER_FLASH_ID_READ;
T_FLASH_ID *upper_flash_id = UPPER_FLASH_ID_READ;

 
The macros expand to this (LOWER_FLASH_ID_BASE_ADDRESS = 0x9D000000 in my case):
 

#define LOWER_FLASH_ID_READ   ((T_FLASH_ID *)KVA0_TO_KVA1(LOWER_FLASH_ID_BASE_ADDRESS))
#define UPPER_FLASH_ID_READ   ((T_FLASH_ID *)KVA0_TO_KVA1(UPPER_FLASH_ID_BASE_ADDRESS))

 
The decision to swap panels in Enter_Application is based on the following:
 

if(upper_flash_id->flash_id > lower_flash_id->flash_id)
{
    SwapFlashPanels(true);
}

 
Can we conclude that, given the state of PFSWAP, that lower_flash_id and upper_flash_id are reading from the same spot in both cases? I don't know that we can, but I'm also not an expert regarding the virtual to physical macros.
 
If this poses a problem then the fix is simple: swap the panels such that PFSWAP is 0, as it would be on a power cycle. The beauty of this solution is this: if it's not a problem then the code will never be executed, and if it is then we know that PFSWAP will be in the correct state before any flash panel manipulation. Thus Microchip's panel switching logic in Enter_Application, which works very well as long as a power cycle is used, has the correct logic and need not be modified.
 
Here is what I have started using without issues; my above attempt didn't work as well (as I found this morning) because I think having PFSWAP set on start up screws with the flash ID logic. I modified the SwapFlashPanels function (similar to a previous post), Enter_Application (to reflect that SwapFlashPanels now takes a boolean argument), and Bootloader_Initialize (now contains a simple if statement that swaps the panels if PFSWAP is 1).
 
Thanks again Ken!
 

#if(BOOTLOADER_LIVE_UPDATE_SWITCHER == 1)
/********************************************************************
* Function:     SwapFlashPanels()
*
* Precondition:
*
* Input:        Boolean indicating Program Flash Bank 2 is to be mapped
*               to the lower mapped region.
*
* Output:
*
* Side Effects:
*
* Overview:     The function will swap the flash panels in a safe
 *              place.
*
*
* Note:         This is placed in the .cache_init section in order
 *              to have it in boot flash rather than program flash.
********************************************************************/
void __longcall__ __attribute__ ((section (".cache_init"))) SwapFlashPanels(bool panel2)
{
    PLIB_NVM_MemoryModifyInhibit(NVM_ID_0);
    PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY1);
    PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY2);
    if (panel2)
    {
        PLIB_NVM_ProgramFlashBank2LowerRegion(NVM_ID_0);
    }
    else
    {
        PLIB_NVM_ProgramFlashBank1LowerRegion(NVM_ID_0);
    }
}
#endif

#if(BOOTLOADER_LIVE_UPDATE_STATE_SAVE != 1)
/********************************************************************
* Function:     Enter_Application()
*
* Precondition:
*
* Input:        None.
*
* Output:
*
* Side Effects: No return from here.
*
* Overview:     The function will program the checksum for the respective
 *              flash panel and jumps to application programmed in it.
*
*
* Note:
********************************************************************/
static void Enter_Application(void)
{
    void (*fptr)(void);

    /* Set default to APP_RESET_ADDRESS */
    fptr = (void (*)(void))APP_RESET_ADDRESS;

#if(BOOTLOADER_LIVE_UPDATE_SWITCHER == 1)
    T_FLASH_ID *lower_flash_id = LOWER_FLASH_ID_READ;
    T_FLASH_ID *upper_flash_id = UPPER_FLASH_ID_READ;

    SYS_DEVCON_InstructionCacheFlush();

    /* Application has been programmed first time into flash panel 1 by the bootloader */
    if( *(uint32_t *)LOWER_FLASH_ID_READ == FLASH_ID_CHECKSUM_CLR &&
        *(uint32_t *)UPPER_FLASH_ID_READ == FLASH_ID_CHECKSUM_CLR)
    {
        /* Program Checksum and initial ID's for both panels*/
        T_FLASH_ID low_flash_id = { 0 };
        T_FLASH_ID up_flash_id = { 0 };
 
        low_flash_id.flash_id = 1;
        low_flash_id.checksum_start = FLASH_ID_CHECKSUM_START;
        low_flash_id.checksum_end = FLASH_ID_CHECKSUM_END;

        up_flash_id.flash_id = 0;
        up_flash_id.checksum_start = FLASH_ID_CHECKSUM_START;
        up_flash_id.checksum_end = FLASH_ID_CHECKSUM_END;
        
        APP_NVMQuadWordWrite((void *)LOWER_FLASH_ID_BASE_ADDRESS, (uint32_t *)&low_flash_id);
        APP_NVMQuadWordWrite((void *)UPPER_FLASH_ID_BASE_ADDRESS, (uint32_t *)&up_flash_id);
    }
    /* If both the panels have proper checksum*/
    else if((lower_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (lower_flash_id->checksum_end == FLASH_ID_CHECKSUM_END) &&
            (upper_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (upper_flash_id->checksum_end == FLASH_ID_CHECKSUM_END))
    {
        if(upper_flash_id->flash_id > lower_flash_id->flash_id)
        {
            SwapFlashPanels(true);
        }
    }
    /* Fallback Cases when either of Panels checksum is corrupted*/
    else if((upper_flash_id->checksum_start == FLASH_ID_CHECKSUM_START) &&
            (upper_flash_id->checksum_end == FLASH_ID_CHECKSUM_END))
    {
        SwapFlashPanels(true);
    }
#endif // BOOTLOADER_LIVE_UPDATE_SWITCHER == 1
    /* Disable Global Interrupts and Jump to Application*/
    PLIB_INT_Disable(INT_ID_0);
    if (bootloaderData.StartAppFunc != NULL)
        bootloaderData.StartAppFunc();
    fptr();
}
#endif // BOOTLOADER_LIVE_UPDATE_STATE_SAVE != 1
 
/******************************************************************************
  Function:
    SYS_MODULE_OBJ Bootloader_Initialize(const SYS_MODULE_INDEX   moduleIndex,
                              const SYS_MODULE_INIT    * const moduleInit)

  Summary:
    Initializes primitive data structures for the general features
    of the primitive layer.

  Description:
    Initializes external and internal data structure for the general
    features of the primitive layer.

    This function must be called at system initialization.

  Remarks:
    None.
*/
void Bootloader_Initialize ( const BOOTLOADER_INIT *drvBootloaderInit )
{
    #if(BOOTLOADER_LIVE_UPDATE_SWITCHER == 1)
    if (PLIB_NVM_ProgramFlashBank2IsLowerRegion(NVM_ID_0))
    {
        SwapFlashPanels(false);
    }
    #endif
    /* Place the App state machine in it's initial state. */
    bootloaderData.currentState = BOOTLOADER_CHECK_FOR_TRIGGER;
    bootloaderData.cmdBufferLength = 0;
    bootloaderData.streamHandle = DRV_HANDLE_INVALID;
    bootloaderData.datastreamStatus = DRV_CLIENT_STATUS_ERROR;
    bootloaderData.usrBufferEventComplete = false;

    bootloaderData.data = &data_buff;
    bootloaderData.type = drvBootloaderInit->drvType;
#ifdef BOOTLOADER_LEGACY
    BootloaderTriggerCheck = drvBootloaderInit->drvTrigger;
#endif
    
    bootloaderData.FlashEraseFunc = (BOOTLOADER_CALLBACK)NULL;
    bootloaderData.StartAppFunc = (BOOTLOADER_CALLBACK)NULL;
    bootloaderData.BlankCheckFunc = (BOOTLOADER_CALLBACK)NULL;
    bootloaderData.ProgramCompleteFunc = (BOOTLOADER_CALLBACK)NULL;
    bootloaderData.ForceBootloadFunc = (BOOTLOADER_CALLBACK)NULL;
    bootloaderData.softReset = (SYS_RESET_ReasonGet() & RESET_REASON_SOFTWARE) == RESET_REASON_SOFTWARE;
#if(BOOTLOADER_LIVE_UPDATE_STATE_SAVE != 1)
    SYS_RESET_ReasonClear(RESET_REASON_SOFTWARE);
    /* Delay to allow the internal pullups to stabilize */
    _CP0_SET_COUNT(0);
    while (_CP0_GET_COUNT() < SYS_CLK_FREQ / 5000);
#endif
}

 
 

事实上，现在我考虑一下，根本不需要编辑Bootloader。C：只需确保程序闪存面板1在BootloadRySuffBootLoloadRever注册的函数中，它就在较低的区域。这样，不需要修改堆栈。



      以下为原文

    Actually, now that I reflect on it, there is no need to edit bootloader.c at all: just make sure that program flash panel 1 is in the lower region by forcing it in the function registered with BOOTLOADER_ForceBootloadRegister. This way, the stack need not be modified.
 

int APP_Bootloader_ForceEvent(void)
{
    /* Ensure that PFSWAP is actually 0 on startup*/
    if (PLIB_NVM_ProgramFlashBank2IsLowerRegion(NVM_ID_0))
    {
        PLIB_NVM_MemoryModifyInhibit(NVM_ID_0);
        PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY1);
        PLIB_NVM_FlashWriteKeySequence(NVM_ID_0, NVM_PROGRAM_UNLOCK_KEY2);
        PLIB_NVM_ProgramFlashBank1LowerRegion(NVM_ID_0);
    }
    
    /* Check the switch press to trigger bootloader */
    if (BSP_SWITCH_STATE_PRESSED == BSP_SwitchStateGet(BTL_TRIGGER_SWITCH))
    {
        return (1);
    }

    /* Check the trigger memory location and return true/false. */
    if (*(uint32_t *)APP_RESET_ADDRESS == 0xFFFFFFFF)
    {
        return (1);
    }
    
    return (0);
}