There is a product replacement bootloader program

  • Description of the requirements

SDK:15.0.0

MCU:NRF52840

I currently have a product that is already in production, and I need to replace its boot program, and the new boot mainly replaces the name of the broadcast and the content of const uint8_t pk[64].

  • Procedure

I have prepared the following:

New boot program with the name: new_boot.hex 、new_private.key。

Private key for the old product: The name is :old_private.key。

I created the zip package using the following command

./nrfutil nrf5sdk-tools pkg generate --hw-version 52 --sd-req 0xA9 --bootloader-version 2 --bootloader ./new_boot.hex --key-file ./old_private.key boot.zip

I used nRF Toolbox to upgrade the device, and the upgrade can be carried out normally, but the program cannot be started normally, and after debugging, I can see that it has entered HardFault。

  • issue
    1. Why does this operation enter the HardFault? How to fix it?
Parents
  • Hello,

    If you update the bootloader that has a new key, then the application needs to be updated as well. Did you do that? You need to generate a new DFU image containing your application that is signed with the new key.

    Best regards,

    Edvin

  • I may have used a boot that differs significantly from the remote boot in the device to create a new boot, rather than just modifying the broadcast name and const uint8_t pk[64] based on the original boot。

    When I only modified the boot broadcast name and const uint8_t pk[64] based on the original boot, it can boot up normally and be replaced.

    But I am still unclear why modifying the boot based on a program with a significantly different boot would lead to failure, even though the modified boot can be used normally.

  • If you change the key of the bootloader, then the old application will be rejected because it is no longer signed with the correct key according to the bootloader. I believe this is what you are seeing.

    Other possibilities are that the bootloader grew in size, eating up parts of the application? Or if you changed the way that the bootloader settings are stored (the parts of flash that stores the application's information), so that the old application is rejected due to that.

    Best regards,

    Edvin

Reply
  • If you change the key of the bootloader, then the old application will be rejected because it is no longer signed with the correct key according to the bootloader. I believe this is what you are seeing.

    Other possibilities are that the bootloader grew in size, eating up parts of the application? Or if you changed the way that the bootloader settings are stored (the parts of flash that stores the application's information), so that the old application is rejected due to that.

    Best regards,

    Edvin

Children
No Data
Related