merging examples with DFU cause NRF_ERROR_NO_MEM

[June20]

Windows 10, Segger Embedded Studio V5.60a

nRF52833-DK (also nRF52840-DK, along with custom boards for each for later purpose)

SDK 17.1.0 S140 

Hello, I'm trying to merge my project (NUS example, BAS, bonding, etc) with DFU bootloader OTA.

It's similar case with https://devzone.nordicsemi.com/f/nordic-q-a/48872/how-to-merge-one-application-with-dfu-feature

I did as instructed. It was built successfully but when executed, I get following errors:

<error> app: No bootloader was found
<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at [my project address] files.c:1105
PC at: 0x000414C5
<error> app: End of error report

the error is pointing to following code:

err_code = ble_dfu_buttonless_async_svci_init();    //nrf_dfu_svci_vector_table_set(),   bootloader_addr != 0xFFFFFFFF problem
APP_ERROR_CHECK(err_code);//NRF_ERROR_NO_MEM

unlike the given link's, I don't get message related to how to reallocate RAM or ROM via debuggin message or Tera Term

my current allocation is as following:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x80000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x20000
FLASH_START=0x27000
FLASH_SIZE=0x59000
FCONFIG_START=0x10000
FCONFIG_SIZE=0x400
DEFAULT_CONFIG_START=0x10500
DEFAULT_CONFIG_SIZE=0x400
INIT_START=0x12000
RAM_START=0x20002be0
RAM_SIZE=0x1d420

macros:

c_preprocessor_definitions="APP_TIMER_V2;APP_TIMER_V2_RTC1_ENABLED;BL_SETTINGS_ACCESS_ONLY;BOARD_PCA10100;BLE_STACK_SUPPORT_REQD;CONFIG_GPIO_AS_PINRESET;FLOAT_ABI_HARD;INITIALIZE_USER_SECTIONS;NO_VTOR_CONFIG;NRF52833_XXAA;NRF_CRYPTO_MAX_INSTANCE_COUNT=1;NRF_SD_BLE_API_VERSION=7;S140;SOFTDEVICE_PRESENT;NRF_DFU_SVCI_ENABLED;NRF_DFU_TRANSPORT_BLE=1;"

What's causing NRF_ERROR_NO_MEM and how to resolve it? 

What is PC at number referring to? Nevermind, found out it was Program counter 

Do I need SW/config modification for custom board?

Thank you in advance

[June20]

Thanks for the reply!

You were right, it was due to lack of bootloader - I didn't program the bootloader. 

So I did 'nrfutil setting' (is nrfutil setting ... same as programming bootloader?)

nrfutil settings generate --family NRF52 --application "my_app.hex" --application-version 0 --bootloader-version 0 --bl-settings-version 2 bootloader_setting_user.hex

I couldn't use 'mergehex', my cmd promt didn't recognize the command. (Python27)

Instead, I used nRF Connect - Programmer v2.3.3.

I added my bootloader_setting_user.hex + my_application.hex + softdevice_s140.hex(found on dfu example) and programmed over it.

Sadly it didn't went well (Sometime same error from 'attach debugger', sometime no response, sometime hardfault error)

About bootloader programming, am I heading the right direction?

I'm on Windows 10 + Python27, how do I get mergehex to work?

Is it alright to use Programmer instead of mergehex?

BTW thanks for the 'Attach Debugger' tip, I was using Segger Studio.

I also rely on 'Tera Term' to debug via serial.

tutorial I was relying on: https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader

[June20]

Okay, I assume I finally built bootloader. However, I didn't go so well.

I got hex file after building SDK/examples/dfu/secure_bootloader/pca10100_s140_ble (secure_bootloader_ble_s140_pca10100.hex)

I got hex file of Softdevice from SDK/components\softdevice\s140\hex\s140_nrf52_7.2.0_softdevice.hex

Built my application and nrfjprog all 4 hex(app, bootloader, bootloader setting, softdevice)

unfortunately my 'attach debugger' doesn't respond (it's just running and not much response from debugger + nothing on my mobile nRF Connect)

Are there things I might have forgot?

Does nrfjprog order matters??

PS, Programmer gave me this response, "Part of the HEX regions are out of the device memory size, but you can still proceed write operation" <- is this safe?

Thanks for replies.

[Edvin]

June20 said:

unfortunately my 'attach debugger' doesn't respond (it's just running and not much response from debugger

If you try to set a breakpoint at the very start of main() in your application before you attach the debugger, is it reached? Have you turned off optimization in your project?

Can you show me all the commands that you use to generate your bl-settings, and then program it?

Can you also send me the files that you are trying to run? Will I be able to reproduce what you are seeing on a DK?

June20 said:

Does nrfjprog order matters??

As long as you don't reset the device between programming the files, it shouldn't matter. That is why I added the line "nrfjprog --reset" at the end, to indicate that you shouldn't call it between every "nrfjprog --program ...".

June20 said:

PS, Programmer gave me this response, "Part of the HEX regions are out of the device memory size, but you can still proceed write operation" <- is this safe?

I have seen this as well. It is a bug in nRF connect for Desktop, because it thinks that the UICR (starting at address 0x10001000) is outside the flash. However, it is not, and using nRF Connect for Desktop to program the device also programs the UICR. You can confirm this by programming the bootloader and reading out the UICR using:

nrfjprog --memrd 0x10001000 --n 128.

It doesn't write much, but you should see two registers holding the addresses of the bootloader and some settings page. (It is written to the UICR->NRFFW registers.

Best regards,

Edvin