nRF SDK Samples Fail to Build with CONFIG_BOOTLOADER_MCUBOOT

I'm working through the process of building and flashing code to a Thingy53 dev kit (nRF5340). I am attempting to generate a DFU compatible build output from a sample but it's failing.

I'm attempted to build and flash the "blinky" example from the zephyr samples included with the SDK install. I copied the "blinky" folder form the install location to my home directory in a working location. If I attempt to build the software without making any changes everything compiles but I only get .hex files in the output. The build succeeds but I don't get all of the possible output file formats.

I was trying to generate the .zip files for the DFU update over USB so I added the line `CONFIG_BOOTLOADER_MCUBOOT=y` to my "prj.conf" file in the blinky directory. When I do this and I re-run the build either through VSCode IDE or through command line with west I get a bunch of errors related to undefined macros. Below is a copy of the errors.

I'm not sure what I am doing wrong, all of the documentation indicates that I can add one line to the conf file and it should build for DFU and generate the output files I desire.

System Setup:
Windows 10
nRF SDK v2.2.0
VSCode Editor w/ all nRF extensions

There are even more errors than what is listed below but these are the first set to fail during the build. It is just more undeclared macros.

C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr/flash_map_extended.c: In function 'flash_area_id_from_multi_image_slot':
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:45:12: error: 'PM_MCUBOOT_PRIMARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
45 | PM_MCUBOOT_PRIMARY_1_ID : \
| ^~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:54:20: note: in expansion of macro 'FLASH_AREA_IMAGE_PRIMARY'
54 | case 0: return FLASH_AREA_IMAGE_PRIMARY(image_index);
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:45:12: note: each undeclared identifier is reported only once for each function it appears in
45 | PM_MCUBOOT_PRIMARY_1_ID : \
| ^~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:54:20: note: in expansion of macro 'FLASH_AREA_IMAGE_PRIMARY'
54 | case 0: return FLASH_AREA_IMAGE_PRIMARY(image_index);
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:50:12: error: 'PM_MCUBOOT_SECONDARY_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
50 | PM_MCUBOOT_SECONDARY_ID: \
| ^~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:56:20: note: in expansion of macro 'FLASH_AREA_IMAGE_SECONDARY'
56 | case 1: return FLASH_AREA_IMAGE_SECONDARY(image_index);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:52:12: error: 'PM_MCUBOOT_SECONDARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
52 | PM_MCUBOOT_SECONDARY_1_ID: \
| ^~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:56:20: note: in expansion of macro 'FLASH_AREA_IMAGE_SECONDARY'
56 | case 1: return FLASH_AREA_IMAGE_SECONDARY(image_index);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
C:/ncs/v2.2.0/bootloader/mcuboot/boot/zephyr/flash_map_extended.c: In function 'flash_area_id_to_multi_image_slot':
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:45:12: error: 'PM_MCUBOOT_PRIMARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
45 | PM_MCUBOOT_PRIMARY_1_ID : \
| ^~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:73:20: note: in expansion of macro 'FLASH_AREA_IMAGE_PRIMARY'
73 | if (area_id == FLASH_AREA_IMAGE_PRIMARY(image_index)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:50:12: error: 'PM_MCUBOOT_SECONDARY_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
50 | PM_MCUBOOT_SECONDARY_ID: \
| ^~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:77:20: note: in expansion of macro 'FLASH_AREA_IMAGE_SECONDARY'
77 | if (area_id == FLASH_AREA_IMAGE_SECONDARY(image_index)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\include\sysflash\sysflash.h:52:12: error: 'PM_MCUBOOT_SECONDARY_1_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?
52 | PM_MCUBOOT_SECONDARY_1_ID: \
| ^~~~~~~~~~~~~~~~~~~~~~~~~
C:\ncs\v2.2.0\bootloader\mcuboot\boot\zephyr\flash_map_extended.c:77:20: note: in expansion of macro 'FLASH_AREA_IMAGE_SECONDARY'
77 | if (area_id == FLASH_AREA_IMAGE_SECONDARY(image_index)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
[89/309] Building C object CMakeFiles/app.dir/C_/ncs/v2.2.0/bootloader/mcuboot/boot/bootutil/src/bootutil_misc.c.obj

Parents
  • Hi

    I'm not sure what I am doing wrong, all of the documentation indicates that I can add one line to the conf file and it should build for DFU and generate the output files I desire.

    I can verify that I see the same output as you when attempting this in nRF Connect SDK (NCS) v2.2.0, which leads me to believe that you might be following the wrong version of the documentation w.r.t which version of the SDK you're using. Could you link med the documentation you've been following so we can cross out if that is the case?

    In nRF Connect SDK v2.3.0 it is sufficient to add this configuration alone*, while in v2.2.0 it is different. *Some modifications may still be required

    In addition to the official documentation on developer.nordicsemi, I also recommend developers who are adding DFU support to their application to have a look at my colleagues Sigurds repository containing relatively minimal samples of ways to implement DFU support for boards. Here you will find both samples and theory/links to documentation explaining various steps: github.com/.../bootloader_samples

     Let me know about the documentation version and we'll get back to get you a blinky sample with DFU support!

    Kind regards,
    Andreas

Reply
  • Hi

    I'm not sure what I am doing wrong, all of the documentation indicates that I can add one line to the conf file and it should build for DFU and generate the output files I desire.

    I can verify that I see the same output as you when attempting this in nRF Connect SDK (NCS) v2.2.0, which leads me to believe that you might be following the wrong version of the documentation w.r.t which version of the SDK you're using. Could you link med the documentation you've been following so we can cross out if that is the case?

    In nRF Connect SDK v2.3.0 it is sufficient to add this configuration alone*, while in v2.2.0 it is different. *Some modifications may still be required

    In addition to the official documentation on developer.nordicsemi, I also recommend developers who are adding DFU support to their application to have a look at my colleagues Sigurds repository containing relatively minimal samples of ways to implement DFU support for boards. Here you will find both samples and theory/links to documentation explaining various steps: github.com/.../bootloader_samples

     Let me know about the documentation version and we'll get back to get you a blinky sample with DFU support!

    Kind regards,
    Andreas

Children
No Data
Related