• State Not Answered
  • Replies 16 replies
  • Subscribers 76 subscribers
  • Views 4820 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 291911
Options

nRF5340 non-simultaneous netcore updates with external QSPI

D Miller

Development Environment: VS Code on Windows 10, SDK: 2.0.0, HW: nRF5340 Development Kit

I am trying to perform just a network core update on the nRF5340 DK based off of the smp_svr sample where the secondary slot for incoming updates is on an external QSPI. Using the Device Manager app, I can perform application core updates without issue, but when doing a network core update, MCUBoot seems to interpret the incoming image as an application core update no matter what. Which causes a second boot cycle as it swaps the images back.

uart:~$ *** Booting Zephyr OS build v3.0.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1
I: Secondary image: magic=good, swap_type=0x2, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: test
I: Starting swap using move algorithm.
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.0.99-ncs1 ***
I: Starting bootloader
I: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: revert
I: Starting swap using move algorithm.
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Bootloader chainload address offset: 0xc000
*** Booting Zephyr OS build v3.0.99-ncs1 ***


[00:00:00.017,791] <inf> smp_sample: build time: Jul 6 2022 15:24:46
[00:00:00.041,656] <inf> smp_bt_sample: Bluetooth initialized
[00:00:00.045,532] <inf> smp_bt_sample: Advertising successfully started

I have an overlay both top level and the child images containing:

// Choose the external flash to be used by partition manager (and allow MCUBoot to use external flash)
/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
};

And the following config files:
prj.conf:

## Bootloader
# Enable mcumgr.
CONFIG_MCUBOOT_IMAGE_VERSION="1.0.0+0"
CONFIG_MCUMGR=y
CONFIG_MCUBOOT_IMG_MANAGER=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

# Some command handlers require a large stack.
CONFIG_MAIN_STACK_SIZE=2048

# Ensure an MCUboot-compatible binary is generated andcanp update the net core
CONFIG_BOOTLOADER_MCUBOOT=y

# Enable flash operations.
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_STREAM_FLASH_ERASE=y

# QSPI for External Flash
CONFIG_SPI=n
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16
CONFIG_NORDIC_QSPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096

# Enable logging
CONFIG_LOG=y
CONFIG_MCUBOOT_UTIL_LOG_LEVEL_WRN=y

# Enable shell commands.
CONFIG_SHELL=y
CONFIG_MCUMGR_CMD_SHELL_MGMT=y

## BLE
# Allow for large Bluetooth data packets.
CONFIG_BT_L2CAP_TX_MTU=498
CONFIG_BT_BUF_ACL_RX_SIZE=502
CONFIG_BT_BUF_ACL_TX_SIZE=502
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251

# Enable the Bluetooth mcumgr transport (unauthenticated).
CONFIG_MCUMGR_SMP_BT=y
CONFIG_MCUMGR_SMP_BT_AUTHEN=n
CONFIG_MCUMGR_SMP_BT_CONN_PARAM_CONTROL=y

# Enable the Shell mcumgr transport.
CONFIG_MCUMGR_SMP_SHELL=y

# Enable the mcumgr Packet Reassembly feature over Bluetooth and its configuration dependencies.
# MCUmgr buffer size is optimized to fit one SMP packet divided into five Bluetooth Write Commands,
# transmitted with the maximum possible MTU value: 498 bytes.
CONFIG_MCUMGR_SMP_REASSEMBLY_BT=y
CONFIG_MCUMGR_BUF_SIZE=2475
CONFIG_OS_MGMT_MCUMGR_PARAMS=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_DEBUG_THREAD_INFO=y
CONFIG_DEBUG_OPTIMIZATIONS=y


child_image/mcuboot.conf:

# MCUboot requires a large stack size, otherwise an MPU fault will occur
CONFIG_MAIN_STACK_SIZE=10240

# Net Core Update Support?
CONFIG_PCD_APP=y
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_STREAM_FLASH=y
CONFIG_STREAM_FLASH_ERASE=y
CONFIG_FLASH_SIMULATOR=y
CONFIG_FLASH_SIMULATOR_DOUBLE_WRITES=y
CONFIG_FLASH_SIMULATOR_STATS=n
CONFIG_MULTITHREADING=y

# This must be increased to accommodate the bigger images.
CONFIG_BOOT_MAX_IMG_SECTORS=256

# External QSPI secondary slot
CONFIG_NORDIC_QSPI_NOR=y
CONFIG_NORDIC_QSPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_NORDIC_QSPI_NOR_STACK_WRITE_BUFFER_SIZE=16

# Various Things to Be small enough but still have logging prints
CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_DEBUG_OPTIMIZATIONS=n
CONFIG_LOG=y
CONFIG_LOG_MODE_MINIMAL=y # former CONFIG_MODE_MINIMAL
CONFIG_LOG_DEFAULT_LEVEL=0

Am I missing something here? I do notice when I debug to MCUBoot's loader.c line 982, where the vector table of the image is grabbed, the loaded data seems to be from the internal flash rather than the external memory. I have gone through the thread here nRF5340 Netcore firmware update using external flash - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com) but my behavior isn't lining up and discussion is all on pre 2.0.0 SDKs. I tried UPGRADE_ONLY but it seems to do the same thing but not be able to revert back and so end up in a boot loop. As said in the title I have no need for simultaneous updates, I am just trying to perform core updates one at a time from the external QSPI.

Attached at the bottom is my minimal reproduction based off of smp_svr. Would greatly appreciate any assistance or pointers on this.

Regards,

D Miller

smp_svr_ext_qspi.zip

Parents
  • 0 in reply to Simon

    I have applied the changes in that commit in the pull request and then tried the removal of the code block also suggested, both to no avail, the system still attempts all updates like they are for the application core.

    I see the intention is to use nrf53_hooks.c to trigger a net core update but those hooks are only called in UPGRADE_ONLY configurations and I wish to retain app core reversion. It seems like the code block that was suggested to be removed in the other ticket is supposed to handle the "one core at a time" netcore updates but the flash simulator in RAM just isn't getting set up to pull the data from the external flash like it is in hooks.

    So, I applied the patch like before which correctly runs the header check, but instead of removing the further down lines as the other thread suggested, I turned them into something closer to what is done in nrf53_hooks.c:

    #if defined(CONFIG_SOC_NRF5340_CPUAPP) && defined(PM_CPUNET_B0N_ADDRESS)
        /* If the update is valid, and it targets the network core: perform the
         * update and indicate to the caller of this function that no update is
         * available
         */
        if (upgrade_valid && reset_addr > PM_CPUNET_B0N_ADDRESS) {
            BOOT_LOG_INF("Starting network core update");
            static const struct device *mock_flash_dev;
            void *mock_flash;
            size_t mock_size;

            BOOT_LOG_INF("Reading update image to flash simulator");
            mock_flash_dev = device_get_binding(PM_MCUBOOT_PRIMARY_DEV_NAME);
            if (mock_flash_dev == NULL) {
                swap_type = BOOT_SWAP_TYPE_NONE;
            }
            mock_flash = flash_simulator_get_memory(mock_flash_dev, &mock_size);
            int rc = flash_area_read(secondary_fa, 0U, mock_flash, hdr->ih_hdr_size + hdr->ih_img_size);
            if (rc != 0) {
                return BOOT_SWAP_TYPE_FAIL;
            }

            BOOT_LOG_INF("Starting PCD update to network core");
            hdr = (struct image_header *) mock_flash;
            uint32_t vtable_addr = (uint32_t)hdr + hdr->ih_hdr_size;
            uint32_t *vtable = (uint32_t *)(vtable_addr);
            rc = pcd_network_core_update(vtable, hdr->ih_img_size);
            if (rc != 0) {
                swap_type = BOOT_SWAP_TYPE_FAIL;
            } else {
                BOOT_LOG_INF("Done updating network core");
#if defined(MCUBOOT_SWAP_USING_SCRATCH) || defined(MCUBOOT_SWAP_USING_MOVE)
                /* swap_erase_trailer_sectors is undefined if upgrade only
                 * method is used. There is no need to erase sectors, because
                 * the image cannot be reverted.
                 */
                rc = swap_erase_trailer_sectors(state,
                    secondary_fa);
#endif
                swap_type = BOOT_SWAP_TYPE_NONE;
            }
        }
#endif /* CONFIG_SOC_NRF5340_CPUAPP */

    I also added the needed includes at the top:

    #if defined(CONFIG_SOC_NRF5340_CPUAPP) && defined(PM_CPUNET_B0N_ADDRESS)
#include <dfu/pcd.h> 
#include "flash_map_backend/flash_map_backend.h"
#include <zephyr/drivers/flash/flash_simulator.h>
#endif

    No other changes to the SDK or project. With this, I can now perform net and app core updates one at a time from a single secondary slot on the external qspi in a way that still allows for reversion of the application core.

    I don't feel like I'm doing everything correctly here, especially with the use of the flash simulator, but I can do my update scheme. I've uploaded my loader.c, otherwise it is v2.0.0 SDK.

    loader.c

  • 0 in reply to Simon

    Hello Miller,

    What is the current state on this? Were you able to implement the changes to a hook file? Unfortunately, I haven't gotten time myself to do it yet. I will be gone for the next two weeks, and my colleague Sigurd will watch the case in the meanwhile (he will be gone until 2 of Aug.). 

    Best regards,

    Simon

  • 0 in reply to Simon

    Hello,

    The tips to get the hooks file started were useful. I am needing to do a little more testing to confirm but I might have a hooks file way to perform this update scheme. Have done a net core update.

    Will know more by the end of the week but I am no longer stuck.

    Thanks,

    Derrick

  • 0 in reply to Simon

    Is it possible to set a path for this file relative to my source directory (such as the hooks file I wish to use being in my project directory)? Seems like the current setup makes it a little hard to introduce the hooks from an out-of-tree application without using an absolute path for the hooks file.

  • 0 in reply to D Miller

    Hi,

    I have explained how to do relative-path MCUBoot keys in another ticket, and I guess you should be able to use the same method for the hooks. I will copy the relevant answer in below here as well, as the context is not really needed:

    "

    Here are some info on how I have been setting the path to the private key for MCUBoot:

    If you have your mcuboot.conf inside the child_image/ folder, the application will look for your key in "ncs/bootloader/mcuboot/boot/zephyr/" I think.

    To work around this, you can create a "child_image/mcuboot" folder, and place the key +  a prj.conf file inside this folder, as I show in my sample. This way, mcuboot will find your key file in your own project (See Multi Image builds for the explanation of this folder setup).

    Another alternative is to use CMake to add the key yourself. To do this, you need some extra apostrophes and backslashes, but the following line into CMakeLists.txt should point to a key in the directory below your source directory.

    set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \\"${CMAKE_CURRENT_SOURCE_DIR}/../private_key.pem\\")

    (Try "message(${CMAKE_CURRENT_SOURCE_DIR}) in CMake to test the path)
    "

    Is this what you were looking for?

    EDIT: Since you use windows, you might have to pay some attention to which way the slashes go in the CMake path definitions. Also from the same post as the one I linked above:
    "Escaping the backslashes may have worked too, but I have only tried just changing all the back slashes to forward slashes. This is probably only going to be an issue on Windows based development systems."

    Regards,
    Sigurd Hellesvik

  • 0 in reply to Simon

    Hi Simon,

    is there any update about a new version of MCUboot which fixes this problem ? I have been told sdk 2.1.0 might contain some fixes, but as far as i can see, it does not. 

    Thanks in advance !

Reply Children
Related
Terms of service