I'm blocked trying to get an Nrf52 application developed under v1.3.0 SDK work with FOTA.
My application is working fine. FYI, its on custom hardware derived from nrf52832_mdk board definition, and the lbs sample.
Now to add FOTA capability. No buttons or display, so buttonless.
I followed the instructions from here,
and I end up with an application that has the DFU characteristic advertised, and nrf connect for mobile and connects to, for DFU. I rebuild an application and try to upload it via NRF Connect, and after a short time of "validating app" on the screen, it reverts back with no error message.
Goggling suggests there is some bug with page alignment fixed mid last year. So I try to copy my application to SDK v1.4.2, and I get a raft of build errors, which cannot be navigated to easily in the IDE. Even the previously supported types like u8_t are no longer valid!
Does anyone have any suggestions? I've used buttonless FOTA on a product on the previous NRF5 SDK with no issues, I'd rather not abandon this mess and go back.
Thank you. This is puzzling, to be honest. Would it be possible to provide your example that reproduce this on a DK, with instructions on how to reproduce? That way I can debug on my side as well…
I have resolved the build issues (header files moved in the SDK); the behaviour is the same. FYI, the changes I made are as follows:
Added to prj.conf:
# Added for FOTACONFIG_BOOTLOADER_MCUBOOT=yCONFIG_MCUMGR=yCONFIG_MCUMGR_CMD_OS_MGMT=yCONFIG_MCUMGR_CMD_IMG_MGMT=yCONFIG_MCUMGR_SMP_BT=yCONFIG_IMG_ERASE_PROGRESSIVELY=y
Added to main.c
// For FOTA#include <tinycbor/cbor.h>#include "cborattr/cborattr.h"#include <mgmt/mgmt.h>#include <mgmt/mcumgr/smp_bt.h>#include <mgmt/mcumgr/buf.h>#include <mgmt/mcumgr/smp.h>#include "os_mgmt/os_mgmt.h"#include "os_mgmt/os_mgmt_impl.h"#include "os_mgmt/os_mgmt_config.h"#include "img_mgmt/image.h"#include "img_mgmt/img_mgmt.h"#include "img_mgmt/img_mgmt_impl.h"#include "img_mgmt/img_mgmt_config.h"
and in main()
printk("Application build time: %s %s \n", __DATE__, __TIME__);
printk("Advertising successfully started\n");
// For FOTA os_mgmt_register_group(); img_mgmt_register_group(); smp_bt_register();
I reloaded the project, built and flashed. The image booted ok
*** Booting Zephyr OS build v2.4.0-ncs2 ***[00:00:00.403,625] <inf> mcuboot: Starting bootloader[00:00:00.409,667] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, cop y_done=0x3, image_ok=0x3[00:00:00.419,677] <inf> mcuboot: Boot source: none[00:00:00.425,140] <inf> mcuboot: Swap type: none[00:00:00.716,369] <inf> mcuboot: Bootloader chainload address offset: 0xc000[00:00:00.724,029] <inf> mcuboot: Jumping to the first image slot*** Booting Zephyr OS build v2.4.0-ncs2 ***Starting Bluetooth Peripheral LBS exampleApplication build time: Feb 23 2021 09:53:14I: 2 Sectors of 4096 bytesI: alloc wra: 0, ff0I: data wra: 0, 0I: SoftDevice Controller build revision:I: cf 5c 0f 11 88 9c d7 02 |.\......I: 15 27 c7 c3 ca 60 19 85 |.'...`..I: b7 c4 50 e3 |..P.I: No ID address. App must call settings_load()Bluetooth initializedAdvertising successfully started
I rebuilt the code, to generate a different binary image (TIME being different) and attempted to DFU this using nrf connect mobile. "Validating" was displayed for a few seconds, then the Android app reverted without attempting the actual DFU.
The target debug output showed
ConnectedDisconnected (reason 19)ConnectedW: Unhandled ATT code 0x1dPasskey for 4d:a0:4e:95:16:f2 (random): 128349Security changed: 4d:a0:4e:95:16:f2 (random) level 4Pairing completed: a8:87:b3:74:2d:56 (public), bonded: 1
I assume I am missing something. Please advise, this product development is now blocked.
By adding the following lines, which I found someone using through a random google search
FOTA now proceeds as expected, although slowly, 1.3KB/s. At the end, the application booted.
A second rebuild of the app failed to download, and the device now no longer gets past the bootloader.
*** Booting Zephyr OS build v2.4.0-ncs2 ***[00:00:00.274,566] <inf> mcuboot: Starting bootloader[00:00:00.280,578] <inf> mcuboot: Primary image: magic=good, swap_type=0x4, copy_done=0x1, image_ok=0x1[00:00:00.290,435] <inf> mcuboot: Boot source: none[00:00:00.295,867] <inf> mcuboot: Swap type: test[00:00:11.931,640] <inf> mcuboot: Bootloader chainload address offset: 0xc000[00:00:11.939,270] <inf> mcuboot: Jumping to the first image slot
So please point us to the correct technique for enabling FOTA.
I do not see that you lack any configurations. You can compare with the smp_svr sample, but this looks good.
What happens after getting "mcuboot: Jumping to the first image slot" in the bootloader log? What state is the nRF in? Do you get more usefull debug information if building with CONFIG_DEBUG_OPTIMIZATIONS=y?
Hi Einar, the device is inoperative after
[00:00:11.939,270] <inf> mcuboot: Jumping to the first image slot
and no further information is displayed.
I will rebuild & reflash with the optimisations enabled, and let you know.
Ah, so adding that debug config caused this to appear, interesting bit in bold
*** Booting Zephyr OS build v2.4.0-ncs2 ***[00:00:00.274,414] <inf> mcuboot: Starting bootloader[00:00:00.280,395] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3[00:00:00.290,313] <inf> mcuboot: Boot source: none[00:00:00.295,776] <inf> mcuboot: Swap type: test[00:00:00.565,460] <wrn> mcuboot: Not enough free space to run swap upgrade[00:00:00.883,209] <inf> mcuboot: Bootloader chainload address offset: 0xc000[00:00:00.890,808] <inf> mcuboot: Jumping to the first image slot*** Booting Zephyr OS build v2.4.0-ncs2 ***Starting Bluetooth Peripheral LBS example
I am building this on NRF52832 - thats only 512KB flash compared to NRF52840 1024KB
Is there an alternative FOTA process without swap method, that can cope with the smaller size? Ive done FOTA on Nordic chips with less memory than 512KB