Building a standalone MCUBOOT APPLICATION

RE: Building a standalone MCUBOOT APPLICATION

raghav_07 — Thu, 14 Mar 2024 11:49:50 GMT

Hi Vidar,

Thank you for the suggestion, I see it is working now. Will test further and perform OTA.

I want to know why the FW is not executing when connected to external power supply and was working fine when connected to EVK even the macro was not set in the bootloader?

What effect does CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC macro make?

RE: Building a standalone MCUBOOT APPLICATION

Vidar Berg — Thu, 14 Mar 2024 09:04:53 GMT

I assume you don't have the 32KHz mounted on your board since you have selected the internal RC oscillator (CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y) in your application. In that case, you need to do the same for the bootloader. Otherwise, the bootloader will become stuck forever waiting for the crystal oscillator to ramp-up.

See 'Permanent configuration changes to child images' for instructions on how you can apply configuration changes to your MCUBoot build.

E.g.,

 # <current-sample> DIRECTORY
    # | - prj.conf
    # | - child_image DIRECTORY
    #     |-- mcuboot.conf   Kconfig fragment for mcuboot containing CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

RE: Building a standalone MCUBOOT APPLICATION

raghav_07 — Thu, 14 Mar 2024 07:22:49 GMT

I checked and verified

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC is not set

RE: Building a standalone MCUBOOT APPLICATION

Vidar Berg — Thu, 14 Mar 2024 07:10:25 GMT

Are you building the bootloader with CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y too? You can verify by checking the build/mcuboot/zephyr/.config output.

RE: Building a standalone MCUBOOT APPLICATION

raghav_07 — Thu, 14 Mar 2024 07:07:32 GMT

ok can u find anything wrong in my configuration in project config which is given bellow if any please let me know

CONFIG_BT=y

CONFIG_BT_CENTRAL=y

CONFIG_BT_AUTO_PHY_UPDATE=n

CONFIG_BT_SCAN=y

CONFIG_BT_SCAN_FILTER_ENABLE=n

CONFIG_BT_MAX_CONN=6

# Allow to read RSSI for the connected peripheral

CONFIG_BT_CTLR_ADVANCED_FEATURES=y

CONFIG_BT_CTLR_CONN_RSSI=y

CONFIG_NEWLIB_LIBC_MIN_REQUIRED_HEAP_SIZE=1024

# Use external clock source

CONFIG_CLOCK_CONTROL_NRF=y

CONFIG_CLOCK_CONTROL=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

# PERIPHERAL

CONFIG_BT_EXT_ADV=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_PER_ADV=y

CONFIG_SETTINGS=y

CONFIG_BT_SETTINGS=y

CONFIG_BT_GATT_CACHING=n

CONFIG_SETTINGS_NONE=y

# Distance Measurement

CONFIG_DM_MODULE=y

CONFIG_NEWLIB_LIBC=y

CONFIG_MPSL=y

CONFIG_MPSL_TIMESLOT_SESSION_COUNT=5

CONFIG_DM_GPIO_DEBUG=n

CONFIG_NCS_SAMPLES_DEFAULTS=y

CONFIG_BT_DEVICE_NAME="Notify"

CONFIG_DM_INITIATOR_DELAY_US=2000

CONFIG_BT_GATT_CACHING=n

CONFIG_SETTINGS_NONE=y

CONFIG_BT_GATT_CLIENT=y

CONFIG_BT_DEBUG_LOG=y

CONFIG_LOG_MAX_LEVEL=0

CONFIG_DM_HIGH_PRECISION_CALC=y

# Enable PWM buzzer module

CONFIG_PRINTK=y

CONFIG_PWM=y

CONFIG_NRFX_GPIOTE=y

CONFIG_NRFX_PDM=y

CONFIG_NRFX_PWM0=y

CONFIG_NRFX_PWM1=y

CONFIG_NRFX_PWM2=y

CONFIG_DEBUG=y

CONFIG_DEBUG_OPTIMIZATIONS=y

CONFIG_DEBUG_THREAD_INFO=y

# Enable ADC

CONFIG_ADC=y

# Enable NVS

CONFIG_NVS=y

CONFIG_FLASH=y

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_MPU_ALLOW_FLASH_WRITE=y

CONFIG_DM_RANGING_OFFSET_US=100000

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=120

CONFIG_BT_PERIPHERAL_PREF_MAX_INT=160

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

CONFIG_REBOOT=y

# Below configurations to enable DFU

# Enable mcumgr.

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU=y

CONFIG_NCS_SAMPLE_MCUMGR_BT_OTA_DFU_SPEEDUP=y

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_SIGN_IMAGES=y

CONFIG_SECURE_BOOT=y

CONFIG_SB_SIGNING_KEY_FILE="priv_key.pem"

CONFIG_BT_L2CAP_TX_MTU=252

CONFIG_BT_BUF_ACL_RX_SIZE=256

# CONFIG_MCUMGR_SMP_BT=y

# CONFIG_MCUMGR_SMP_BT_AUTHEN=n

# Some command handlers require a large stack.

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

RE: Building a standalone MCUBOOT APPLICATION

Vidar Berg — Thu, 14 Mar 2024 06:43:08 GMT

There aren't any obvious reasons, or at least none that I can think of, to explain why your device becomes stuck in the bootloader when you change the power supply. This is why I need your help to troubleshoot the problem.

RE: Building a standalone MCUBOOT APPLICATION

raghav_07 — Thu, 14 Mar 2024 04:45:24 GMT

Hi,

Thanks for the response,

The device will not run our application it got hangs in bootloader we can not able to determine where it hangs when we connect our device to an external supply if we are getting power supply from dev kit then there is no issue our application running fine so my only issue is with external power supply so kindly resolve it.

thanks in advance

RE: Building a standalone MCUBOOT APPLICATION

Vidar Berg — Wed, 13 Mar 2024 09:49:15 GMT

What happens when you start a debug session in VS code, are you not able to see where it hangs in the bootloader? You should be able to debug the bootloader with your existing project.

RE: Building a standalone MCUBOOT APPLICATION

raghav_07 — Wed, 13 Mar 2024 09:31:53 GMT

As its not running application we can not debug it and as per logging we don't have uart so we can not enable

RE: Building a standalone MCUBOOT APPLICATION

Vidar Berg — Wed, 13 Mar 2024 07:22:07 GMT

Have you attempted any debugging or enabled logging as I suggested?

RE: Building a standalone MCUBOOT APPLICATION

raghav_07 — Wed, 13 Mar 2024 04:47:44 GMT

hi,

thanks for the response I tried the solution what u gave me but my problem not yet solved I will tell u what's exactly happening, our device in which we implemented mcuboot loader when the device is getting power supply from dev kit its working fine but when we connect to external supply the device is not running our application if we remove bootloader its working fine but we need bootloader in our application kindly give any kind of solution for this

RE: Building a standalone MCUBOOT APPLICATION

Vidar Berg — Mon, 11 Mar 2024 14:21:40 GMT

Hi,

I recommend debugging the bootloader that was built as a 'child-image' of your main application instead. If you build the bootloader as a standalone application, you will need to manually sign the application image, which is done automatically by the build process otherwise.

I recommend enabling logging from the bootloader if possible. Please see this post for instructions: RE: mcumgr: The firmware doesn't boot up after upload

Best regards,

Vidar