Stuck with bootloader sample

RE: Stuck with bootloader sample

Bruno Miguelez — Fri, 11 Nov 2022 09:57:08 GMT

We managed to make it work not exactly as the fota upgrades documentation said but using some of the code from the smp_svr sample.

We are working on changing our app from 1.9.1 to 2.1.1, we will let you know if we have any issue swithching versions. Thanks for your help.

RE: Stuck with bootloader sample

Vidar Berg — Fri, 04 Nov 2022 08:07:00 GMT

[quote user="Bruno Miguelez"]We then downloaded version 2.1.1 from nrf toolbox and we tried to flash that smp_svr sample and it worked perfectly. Our app is almost finished in version 1.9.1, so we will try to change it to 2.1.1, this should be pretty straight forward right?.[/quote]

The only big change I can think of that may require some migration effort is the introduction of Pin control: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/migration/migration_guide_1.x_to_2.x.html#pin-control-transition. This will be relevant if you used custom DT overlay or board files in your existing project based on 1.9.1.

[quote user="Bruno Miguelez"] img_mgmt_register_group() and smp_bt_register() in the app) as well as the overlay-bt.conf overlay however it did not work for us, any suggestions?, is there a specific place in the code where we should add the functions above?[/quote]

It should not matter where these functions are called. Have you enabled logging to see if there are any error messages? And did you get any build warnings?

RE: Stuck with bootloader sample

Bruno Miguelez — Thu, 03 Nov 2022 09:41:48 GMT

We have now tested the hex file you sent and it worked fine, the phone was able to find the board and the dfu could be done. We then tried it again with version 1.9.1 and a different phone could not find the board but the one we used for version 2.1.1 could. However when trying to dfu with version 1.9.1 it did not work.

We then downloaded version 2.1.1 from nrf toolbox and we tried to flash that smp_svr sample and it worked perfectly. Our app is almost finished in version 1.9.1, so we will try to change it to 2.1.1, this should be pretty straight forward right?.

We then tried building with version 2.1.1 the blinky sample adding the lines mentioned in the fota upgrades documentation ( CONFIG_MCUMGR_CMD_OS_MGMT, CONFIG_MCUMGR_CMD_IMG_MGMT, and CONFIG_MCUMGR_SMP_BT in prj.conf and os_mgmt_register_group(), img_mgmt_register_group() and smp_bt_register() in the app) as well as the overlay-bt.conf overlay however it did not work for us, any suggestions?, is there a specific place in the code where we should add the functions above?

RE: Stuck with bootloader sample

Bruno Miguelez — Wed, 02 Nov 2022 17:35:00 GMT

Yes, we are still working on our NRF52 DKs. I will try to flash the hex file and I will let you know if it works. Thanks

RE: Stuck with bootloader sample

Vidar Berg — Tue, 01 Nov 2022 09:45:42 GMT

Are you still using your nRF52 DKs to test with? The example should just work in that case.

Could you try to flash the hex file below to see if you get the same result? It's from the smp srv in SDK 2.1.1 built for nrf52dk_nrf52832.

devzone.nordicsemi.com/.../3817.merged.hex

RE: Stuck with bootloader sample

Bruno Miguelez — Mon, 31 Oct 2022 16:56:24 GMT

Just as you suggested, we forgot to build with the overlay-bt.conf overlay. However we have now tried it again, with the SMP server sample and with a different app adding in both the overlay-bt.conf, but the same thing happens. It still does not appear in the phone's bluetooth near devices. Any idea of why this could be happening?

RE: Stuck with bootloader sample

Vidar Berg — Mon, 24 Oct 2022 11:38:47 GMT

Hello,

I'm glad to hear that it's not an issue to switch over the 52832.

[quote userid="120136" url="~/f/nordic-q-a/92696/stuck-with-bootloader-sample/392124"]So a change to the 832 will fix both issues right? So there is no need to add the SPI IC if we change to 832 right?[/quote]

Probably yes, but it will depend on the size of your application.

[quote userid="120136" url="~/f/nordic-q-a/92696/stuck-with-bootloader-sample/392124"]We then tried with by flashing the SMP Server Sample app and got the same results. Do you have any idea of why this could be happening?[/quote]

Did you remember to build with the overlay-bt.conf overlay? This will enable the FOTA over BLE support.

Flash layout SMP SRV with BLE FOTA on 'nrf52dk_nrf52832' and SDK v2.1.1 (MCUBoot size can be reduced to 24K if needed):

RE: Stuck with bootloader sample

Bruno Miguelez — Mon, 24 Oct 2022 11:22:11 GMT

Hello

Thank you for your response. It is not a big issue for us to change from the 810 to the 832. However we don't like that much the idea of adding a SPI Flash IC. From what we understood, what you tried to do was to follow the FOTA Uprades documentation with the external SPI flash IC and the 810 because the 810 doesn't have enough Flash, but when trying this it turns out that it doesn't have enough RAM either. So a change to the 832 will fix both issues right? So there is no need to add the SPI IC if we change to 832 right?

We are working right now with the DK so it is not a big deal for us to change to the 832, in fact we have already tried to follow the same FOTA Upgrades documentation that you mentioned with the mcumgr with 832. We added CONFIG_MCUMGR_CMD_OS_MGMT, CONFIG_MCUMGR_CMD_IMG_MGMT, and CONFIG_MCUMGR_SMP_BT in prj.conf and os_mgmt_register_group() and img_mgmt_register_group() in the app, as well as smp_bt_register(). Then we tried using the nrf Connect Device Manager app in our mobile phone to start BLE communication but it turns out the board wasn't advertising or at least our phone couldn't find it in its nearby bluetooth devices. We then tried with by flashing the SMP Server Sample app and got the same results. Do you have any idea of why this could be happening?

It is worth mentioning that all we need from the dfu is to replace the existing application with the new version, we don't need to upgrade neither the softdevice or the bootloader itself, so what we would like is the most straight forward way of doing this through BLE. Thank you so much for your responses again.

RE: Stuck with bootloader sample

Vidar Berg — Wed, 19 Oct 2022 08:07:17 GMT

Hello,

I'm afraid you will not be able to DFU over BLE working on the 52810 because of the limited amount RAM and FLASH you have available. You need to be able to fit the application and MCUBoot inside the internal flash as well as having enough RAM to include the DFU related modules. Also, for DFU over BLE, an external SPI flash IC will be required as the application needs a place to store the new FW image before it gets activated by the bootloader.

I did as a test try to configure an example with external flash and BLE DFU support following the steps in "FOTA upgrades", but I struggled to get the RAM usage below 40 K, which is way above what the 52810 has. So it does not look promising, unfortunately.

Memory layout for illustration

The B0 Bootloader (nRF Secure Immutable Bootloader) is for added security and is targeted for the larger variants of the 52 family. It's not suitable for the 52810 because of the memory constraints. It also does not handle DFU (the application and/or MCUBoot is responsible for that).

[quote user=""]nrfutil dfu serial -pkg /path/to/blinky_fast.zip -p /dev/tty.usbmodem0006825573701 -b 115200[/quote]

nrfutil is for performing DFU over the Secure DFU protocol used in the nRF5 SDK. The equivalent tool for this in the nRF connect SDK is the mcumgr cli: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#installing-the-mcumgr-cli

I understand that it is not desirable to change the chip variant at this stage, but is it something you could consider? You can find an overview of the different nRF52 variants here: nRF52 Series

Best regards,

Vidar

RE: Stuck with bootloader sample

Susheel Nuguru — Wed, 19 Oct 2022 04:43:56 GMT

Sorry for the late response, I would ask my colleague to help as I do not have experience with the older versions of bootloader.

RE: Stuck with bootloader sample

Bruno Miguelez — Fri, 14 Oct 2022 09:05:18 GMT

We have checked UART configuration in both ends and tried with lower baudrates too, but we get the same result. We have also tried connecting an external UART cable directly to the pins instead of using the micro usb cable but it didn't change anything either. We don't really understand when does the board wait for dfu communication with pc. As we specified above, when adding the CONFIG_SECURE_BOOT=y it then prints out the messages above, so we know that it goes into the dfu code. However, in older versions we have read that it used to wait for button 4 to be held during a reset to stay in the dfu code and waiting for communication with the PC. We are not sure if ours is waiting for communication with the PC as it seems to go immediatly into the app image.

RE: Stuck with bootloader sample

Susheel Nuguru — Mon, 10 Oct 2022 12:36:22 GMT

Not an expert in the DFU stuff but it seems like your image package seems ok but the transfer is not able to go further because of the UART communication. Are you sure that the UART on both ends are configured correctly? (correct baudrate and correct flow control configured)