device reset after OTA update, no MCUBOO rtt logs

I come after this post.
After following these steps i was unable to view RTT logs of the MCUBOOT.
I am at Zephyr 2.6.99, nrd sdk 1.7.1 and working on OTA updates for a custum nrf52840 circuit board, that has RTT logging.
The debbugger is a J-link EDU debugger. I am getting my applications RTT logs normaly, but no logs from MCUBoot.
I was able to perform an OTA update with the nrf52840 dongle, and on my custom nrf52840 circuit board with the
smp sample provided inside ~/ncs/zephyr/samples/subsys/mgmt/mcumgr/smp_svr by sendins an update 
with the Device Manager APP.

I am having trouble performing an OTA update with my application. After i integrated the SMP service,
i see the advertisement, i follow the same steps, as with the SMP sample, and my device just resets after the 
upload is fineshed. Show i want to be able to see MCUBOOT logs for debugging perpuses.
For the record, i also read the flash memory before and after the OTA update with nrf's Connect programmer.
With the smp_srv sample, after the update i can see that slot0 and slot1 have swapped places.
With my smp integration, the flash remains unchanged before and after the OTA update. Meaning that slot1 is empty
and slot0 has the origian application binary.

SMP samples's binary is 178KB , as well as the ota update binary
My application's size with the smp service integrated is 300KB , and ota binary is 301KB
Here is my flash partitioning:

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x0000C000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x00067000>;
		};
		slot1_partition: partition@73000 {
			label = "image-1";
			reg = <0x00073000 0x00067000>;
		};
		scratch_partition: partition@da000 {
			label = "image-scratch";
			reg = <0x000da000 0x0001e000>;
		};

		/*
		 * The flash starting at 0x000f8000 and ending at
		 * 0x000fffff is reserved for use by the application.
		 */

		/*
		 * Storage partition will be used by FCB/LittleFS/NVS
		 * if enabled.
		 */
		storage_partition: partition@f8000 {
			label = "storage";
			reg = <0x000f8000 0x00008000>;
		};
	};
};


Parents
  • Hi, 

    Check out this post

    If that cannot help, please provide the child_image\mcuboot.conf.

    Regards,
    Amanda H.

  • Hello Amanda,
    as i said, i  allready followed the changes of the post that you provided.
    The only change i had to was to comment:
    CONFIG_BOOT_ENCRYPT_IMAGE=n
    in prf.conf of bootloader
    since at build time i got this error:ncs/bootloader/mcuboot/boot/zephyr/prj.conf:7: warning: attempt to assign the value 'n' to the undefined symbol BOOT_ENCRYPT_IMAGE

    error: Aborting due to Kconfig warnings

    Here is my child_image\mcuboot.conf:

    CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000
    
    # Disable UART Console and enable the RTT console
    CONFIG_UART_CONSOLE=n
    CONFIG_RTT_CONSOLE=y
    CONFIG_USE_SEGGER_RTT=y
    
    # Config logger
    CONFIG_LOG_BACKEND_RTT=y
    CONFIG_LOG_BACKEND_UART=n
    
    CONFIG_MULTITHREADING=y

    Thank you for your time!

  • I would suggest you use UART for debug logs to avoid potential issues.

  • It's true, on nrf52840 DK, i was able to see bootloader logs from uart.
    My custom circuit board has a only a 6pin jtag connector, no usb output.
    Is it possible to debug through UART ?

  • Hello Amanda, i followed your suggestion on using UART for debugging. I resorted on using the nrf52840dk.
    i got these logs from mcuboot:

    *** Booting Zephyr OS build v2.6.99-ncs1-1  ***
    
    I: Starting bootloader
    
    I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    
    I: Secondary image: magic=good, swap_type=0x3, copy_done=0x3, image_ok=0x1
    
    I: Boot source: none
    
    I: Swap type: perm
    
    E: Image in the secondary slot is not valid!
    
    I: Bootloader chainload address offset: 0xc000
    
    I: Jumping to the first image slot
    
    

    after that my device resets to the original flashed binary as i decribed earlier. I also check the flash
    memory map with the nrf connect programmer app, and to me surprise, the secondary slot was empty.
    I other words, the flash map was the same before and after the OTA update.

    For referenece these are the UART logs i got when i managed to perform an OTA update with the smp_srv sample using overlay-bt.conf :

    How can i approach this "Image in the secondary slot is not valid!" error ?

  • Hi, 

    Do you update the file with modifications?

    Do you update the file with the same memory layout?

    To perform DFU, you must define a static partition map because the dynamically generated partitions can change between builds. This is also important when you use a precompiled HEX file as a child image instead of building it. In such cases, the newly generated application images may no longer use a partition map compatible with the partition map used by the bootloader. As a result, the newly built application image may not be bootable by the bootloader. See Static partition requirement for DFU doc. 

    To create pm_static, I would start by doing the following:

    1. Open sample_pm_static.yml
    2. Open your old build/partitions.yml
    3. Observe that the content in the autogenerated file is similar to the pm_static file from the two files above.
    4. Open <your_project>/pm_static.yml
    5. Copy app and mcuboot content from partitions.yml to pm_static.yml
    6. Compare with sample_pm_static.yml and remove all parts of yml that are not needed (such as end_address)
    7. Try to build the project.

    Please be aware that NCS 1.7.1 is pretty old. I would suggest you move to the latest version NCS v2.5.2 for bug fixings.

    -Amanda H.  

Reply
  • Hi, 

    Do you update the file with modifications?

    Do you update the file with the same memory layout?

    To perform DFU, you must define a static partition map because the dynamically generated partitions can change between builds. This is also important when you use a precompiled HEX file as a child image instead of building it. In such cases, the newly generated application images may no longer use a partition map compatible with the partition map used by the bootloader. As a result, the newly built application image may not be bootable by the bootloader. See Static partition requirement for DFU doc. 

    To create pm_static, I would start by doing the following:

    1. Open sample_pm_static.yml
    2. Open your old build/partitions.yml
    3. Observe that the content in the autogenerated file is similar to the pm_static file from the two files above.
    4. Open <your_project>/pm_static.yml
    5. Copy app and mcuboot content from partitions.yml to pm_static.yml
    6. Compare with sample_pm_static.yml and remove all parts of yml that are not needed (such as end_address)
    7. Try to build the project.

    Please be aware that NCS 1.7.1 is pretty old. I would suggest you move to the latest version NCS v2.5.2 for bug fixings.

    -Amanda H.  

Children
  • Hello Amanda,
    the sample_pm_static.yml file that you provided, appears to be invalid (i get error 404 file not found)
    I did copy the partitions.yml from /build directory of my project inside my project directory.
    Basicaly i get this behavior:
    - when my OTA update fails (Device Manager application's progress bar stops) i notice that the secondary partition that is reserved for the OTA update binary, is filled partialy. 
    OTA update fails frequently though... i do not get any log for this failure.
    - when my OTA update seems to have been send (progress bar is full) , same behavior as previously. My application resets, and seconadary partition is empty!
    Here is my pm_static.yml:

    app:
      address: 0xc200
      end_address: 0x83000
      region: flash_primary
      size: 0x76e00
    littlefs_storage:
      address: 0xfa000
      end_address: 0x100000
      placement:
        before:
        - end
      region: flash_primary
      size: 0x6000
    mcuboot:
      address: 0x0
      end_address: 0xc000
      placement:
        before:
        - mcuboot_primary
      region: flash_primary
      size: 0xc000
    mcuboot_pad:
      address: 0xc000
      end_address: 0xc200
      placement:
        align:
          start: 0x1000
        before:
        - mcuboot_primary_app
      region: flash_primary
      size: 0x200
    mcuboot_primary:
      address: 0xc000
      end_address: 0x83000
      orig_span: &id001
      - app
      - mcuboot_pad
      region: flash_primary
      sharers: 0x1
      size: 0x77000
      span: *id001
    mcuboot_primary_app:
      address: 0xc200
      end_address: 0x83000
      orig_span: &id002
      - app
      region: flash_primary
      size: 0x76e00
      span: *id002
    mcuboot_secondary:
      address: 0x83000
      end_address: 0xfa000
      placement:
        after:
        - mcuboot_primary
        align:
          start: 0x1000
      region: flash_primary
      share_size:
      - mcuboot_primary
      size: 0x77000
    sram_primary:
      address: 0x20000000
      end_address: 0x20040000
      region: sram_primary
      size: 0x40000

    My ota update binary also has static partitioning, same way as my primary application.

    Also i got another question about NCS sdk version. Can i use the latest NCS sdk while i am at Zephyr 2.6.99, or shoud they updated together ?
    We have tried to move to a newer Zephyr version, so we can enjoy the latest NCS sdk, but the transition is rough since we are using I2C DMA and the custom driver used fot that is written with NCS sdk 1.7.1.

  • Hi, 

    Did you modify the updated application? If so, what is that?

    Could elaborate on the detail what is the difference between the original and updated image? Is any config changed?

    If you update the image without modification, it will not be valied.

    apogatz98 said:
    Can i use the latest NCS sdk while i am at Zephyr 2.6.99, or shoud they updated together ?

    Do you mean to update from NCS v1.7.1 to the latest NCS? If so, it's possible with the same memory lay by pm_static.yml. 

    apogatz98 said:
    We have tried to move to a newer Zephyr version, so we can enjoy the latest NCS sdk, but the transition is rough since we are using I2C DMA and the custom driver used fot that is written with NCS sdk 1.7.1.

    If you want to move to the latest NCS, you have to migrate the custom driver to be compatible with the latest version. Here are the Migration guides, but I would suggest migrating to v2.0.0 for the first step since there are some big changes in v2.0.0.  Make sure the application can run with the latest NCS without issue, and then add the DFU features to test.

     

    Regards,
    Amanda H.

  • Did you modify the updated application? If so, what is that?

    Could elaborate on the detail what is the difference between the original and updated image? Is any config changed?

    Hello Amanda. The only difference between the main application binary and the update binary is essentially:
    1)The build time. The update binary is built a few minutes later than the the main binary
    2)A print statement in the main function:
    - The update binary spams with a k timer every 2 seconds "I am a OTA Update"
    - The main binaryu spams with a ktimer every 2 seconds "I am an SMP Server"
    The ota update contains the same smp server, it's just a debug message to distinguish them.
    Everythings else, is the same, even the pm_static.yml.
    Keep in mind that all the above, do work with the smp_srv sample. My current issue with my application is that the either the update proccess stops (device manager progress bar freezes) or if the update is sent successfully i get the error:
    Image in the secondary slot is not valid!
    And the device resets to the main application.

    Do you mean to update from NCS v1.7.1 to the latest NCS?

    I mean, generally, is it possible to update from NCS v1..7.1 to the latest NCS but keeping the same Zephyr version?
    I think the oppostie questions makes more sense. Can i update to the latest Zephyr version but keep the NCS version 1.7.1.?

  • Hi,

    apogatz98 said:
    Keep in mind that all the above, do work with the smp_srv sample. My current issue with my application is that the either the update proccess stops (device manager progress bar freezes) or if the update is sent successfully i get the error:

    Did you have the same changes with your application? As I explained, updating an unmodified image would get that error. 

    apogatz98 said:
    Can i update to the latest Zephyr version but keep the NCS version 1.7.1.?

    No, the NCS only supports the corresponding Zephyr version. 

    -Amanda H.

  • Hello Amanda,
    i just figured out that the whole issue was caused due to the following configs

    CONFIG_BT_BUF_ACL_RX_SIZE=256
    CONFIG_BT_L2CAP_TX_MTU=252
    , in my application, these values where set to 512.
    Now OTA works as expected.
    Thank you for your effort, and continuous support! This
    ticket can be closed.
Related