NORA-B126 flash overflow

Hi,

we are trying to make the NORA-B126 (specifically its onboard LNA) work with nrf sdk 2.3.0 by modifying the 5340dk dts and defconfig files as specified in the NORA-B1_SIM_UBX-20027617.pdf

But it looks like the firmware won't fit anymore in the flash, and even trying to increase the flash sizes in the QKAA files has zero effects on the overflow reported.

zephyr\zephyr_pre0.elf section `text' will not fit in region `FLASH'
region `FLASH' overflowed by 12540 bytes
modules/nrf/lib/multithreading_lock/lib..__nrf__lib__multithreading_lock.a(multithreading_lock.c.obj): in function `k_mutex_lock':
build\multiprotocol_rpmsg\b0n/zephyr/include/generated/syscalls/kernel.h:955: undefined reference to `z_impl_k_mutex_lock'
modules/nrf/lib/multithreading_lock/lib..__nrf__lib__multithreading_lock.a(multithreading_lock.c.obj): in function `k_mutex_unlock':
b0n/zephyr/include/generated/syscalls/kernel.h:971: undefined reference to `z_impl_k_mutex_unlock'
modules/nrf/subsys/mpsl/init/lib..__nrf__subsys__mpsl__init.a(mpsl_init.c.obj): in function `mpsl_low_prio_irq_handler':
undefined reference to `k_work_submit_to_queue'
modules/nrf/subsys/mpsl/init/lib..__nrf__subsys__mpsl__init.a(mpsl_init.c.obj): in function `mpsl_low_prio_init':
undefined reference to `k_work_queue_start'
undefined reference to `k_work_init'
in function `k_sem_give':
undefined reference to `z_impl_k_sem_give'
in function `nrf_flash_sync_init':
undefined reference to `z_impl_k_sem_init'
in function `k_sem_take':
undefined reference to `z_impl_k_sem_take'
in function `k_sem_reset':
undefined reference to `z_impl_k_sem_reset'
collect2.exe: error: ld returned 1 exit status

Parents
  • I did some digging and I found a solution, granted, I need to do more testing to verify but at least it builds.

    Here is some given variables by the nrf connect sdk.

    In order to do gpio LNA, you need MPSL.
    in order to do MPSL you need clock functionality, so setting

    CONFIG_SYS_CLOCK_EXISTS=n

    is not good. Because you will get 2 errors:
    /opt/nordic/ncs/v2.3.0/nrf/subsys/mpsl/init/mpsl_init.c:192:10: error: #error "Clock source is not supported or not defined

    and

    /opt/nordic/ncs/v2.3.0/nrf/subsys/mpsl/init/mpsl_init.c:203:34: error: 'CONFIG_CLOCK_CONTROL_NRF_ACCURACY' undeclared (first use in this function)

    so anything that sets that config flag in your netcore will stop your LNA application from working.

    also, if you do anything that needs rpmsg like ble or zigbee for example, you need some kernel functions like z_impl_k_sem_reset etc.
    so setting:

    CONFIG_MULTITHREADING=n

    is also bad news.

    now for the flash overflow issue, you did not provide the full build log, so IDK if you're having the same problem as I am, but I will share my experience anyway, maybe it helps you.

    I was setting

    CONFIG_BOOTLOADER_MCUBOOT=y

    in my app core.
    This has a bunch of unintended consequences. first of all, make sure that you have a child_image file with mcuboot.conf inside of it, and set the correct size for mcuboot, if the error for flash overflow in your application is related to mcuboot, this is probably the culprit, make sure to mirror all the other settings of your pm_static.yml if you have it in your project, make sure your app_core partitions are setup correctly, etc.

    the second thing that happens when you enable mcuboot in your app_core, is it automatically builds the secure_boot bootloader for your net_core. The code for this is buried in nrf/samples/nrf5340/netboot application.

    CONFIG_B0N_SIZE


    defined in the kconfig file in that app too low. specifically, it needed to be increased 0x3000 to fit whatever things are needed (or most likely not needed) in the background.
    The  proj.conf file in that application was also setting multithreading to off, and it was setting sys_clock_exists to off, which is the reason for me to have the kernel functions not available in my rpmsg app, and the reason why mpsl was not able to build due to clock issues.

    the way i fixed it, is i strait up  edited the CONFIG_B0N_SIZE to fit the flash overflow error I was experiencing, and enabled back multithreading and sys_clock.

    if your issue is not from within mcuboot, then make sure nothing else is turning off multi-threading deep in your application, and check which image is unable to build due to flash size issues.

    I hope the nrf support agent is able to elaborate on why my application was trying so hard to kill itself, and if my issue does not remotely relate to yours, then I am sorry for wasting your time.

Reply
  • I did some digging and I found a solution, granted, I need to do more testing to verify but at least it builds.

    Here is some given variables by the nrf connect sdk.

    In order to do gpio LNA, you need MPSL.
    in order to do MPSL you need clock functionality, so setting

    CONFIG_SYS_CLOCK_EXISTS=n

    is not good. Because you will get 2 errors:
    /opt/nordic/ncs/v2.3.0/nrf/subsys/mpsl/init/mpsl_init.c:192:10: error: #error "Clock source is not supported or not defined

    and

    /opt/nordic/ncs/v2.3.0/nrf/subsys/mpsl/init/mpsl_init.c:203:34: error: 'CONFIG_CLOCK_CONTROL_NRF_ACCURACY' undeclared (first use in this function)

    so anything that sets that config flag in your netcore will stop your LNA application from working.

    also, if you do anything that needs rpmsg like ble or zigbee for example, you need some kernel functions like z_impl_k_sem_reset etc.
    so setting:

    CONFIG_MULTITHREADING=n

    is also bad news.

    now for the flash overflow issue, you did not provide the full build log, so IDK if you're having the same problem as I am, but I will share my experience anyway, maybe it helps you.

    I was setting

    CONFIG_BOOTLOADER_MCUBOOT=y

    in my app core.
    This has a bunch of unintended consequences. first of all, make sure that you have a child_image file with mcuboot.conf inside of it, and set the correct size for mcuboot, if the error for flash overflow in your application is related to mcuboot, this is probably the culprit, make sure to mirror all the other settings of your pm_static.yml if you have it in your project, make sure your app_core partitions are setup correctly, etc.

    the second thing that happens when you enable mcuboot in your app_core, is it automatically builds the secure_boot bootloader for your net_core. The code for this is buried in nrf/samples/nrf5340/netboot application.

    CONFIG_B0N_SIZE


    defined in the kconfig file in that app too low. specifically, it needed to be increased 0x3000 to fit whatever things are needed (or most likely not needed) in the background.
    The  proj.conf file in that application was also setting multithreading to off, and it was setting sys_clock_exists to off, which is the reason for me to have the kernel functions not available in my rpmsg app, and the reason why mpsl was not able to build due to clock issues.

    the way i fixed it, is i strait up  edited the CONFIG_B0N_SIZE to fit the flash overflow error I was experiencing, and enabled back multithreading and sys_clock.

    if your issue is not from within mcuboot, then make sure nothing else is turning off multi-threading deep in your application, and check which image is unable to build due to flash size issues.

    I hope the nrf support agent is able to elaborate on why my application was trying so hard to kill itself, and if my issue does not remotely relate to yours, then I am sorry for wasting your time.

Children
  • Your initial configs did help solve a few dependencies errors, but the overflow (of b0n) is still there. I'm seeing very inconsistent results by changing the B0N_SIZE, often times it says error: static assertion failed: "PM_B0N_CONTAINER_SIZE % CONFIG_FPROTECT_BLOCK_SIZE was not 0. Check the B0_SIZE Kconfig." even if the set number is divisible by 2000, 2048 or 16384 (I'm not even sure which is the correct one).

  • i didn't even worry about the 2k thing, just make sure you have the amount of flash that you set aside for your b0n not occupied by anything else. maybe post the full build error in a code bock and see what it says. my entire process to get this thing to work which i tested now and thankfully it does, was to just track down all the different configs in the different child images and suppress anything that is unsetting something I am using.

Related