Issue with Matter Template Code in nRF Connect SDK v2.6.0 on Custom Board

[Ashique]

I'm encountering an issue with the Matter template code in nRF Connect SDK v2.6.0 on my custom board. Strangely, the same code runs perfectly fine on my board when using the example code from the previous SDK version, v2.4.0.

In my debugging, I've observed that the code is not jumping to the application image from the bootloader. It seems to be stuck in the bootloader itself.

Could someone help me understand why this might be happening? Are there any specific changes or configurations required in nRF Connect SDK v2.6.0 that could affect the compatibility with custom boards, particularly regarding bootloader operation?

[Amanda Hsieh]

Hi, 

Do you use a static partition file like this pm_static_nrf52840dk_nrf52840.yml?

Does your custom board use the external flash? via SPI or QSPI?

Is it nRF52840 or nRF5340 on your custom board?

Are you able to reproduce the issue on nRF52840DK?

Regards,
Amanda H.

[Ashique]

Thank you for your response.

I appreciate your suggestions. However, I'd like to provide some additional information. I have not made any changes to the example code provided in the nRF Connect SDK v2.6.0. There have been no configuration alterations or partition changes either. My custom board is based on the nRF52840 chip, and it does not utilize any external flash via SPI or QSPI

Interestingly, the code runs perfectly fine on the nRF52840 Development Kit (DK). However, on my custom board, it seems to be stuck in the bootloader without transitioning to the application image.

I hope this additional information helps in diagnosing the issue further.

[Amanda Hsieh]

Hi, 

I would suggest you create a new support case for board design review.

-Amanda H. 

[Ashique]

Furthermore, I've observed that older versions of the template work perfectly on my custom board. Specifically, the Matter template code below the nRF Connect SDK 2.4.0 functions properly.

[Ashique]

# Disable Matter OTA DFU

CONFIG_CHIP_OTA_REQUESTOR=n

Adding the configuration to the prj.conf file resolved the issue. However, I'm curious to understand why this adjustment was necessary for the newer version of the SDK.

Could you provide an explanation or insight into why adding this configuration made the code work on my custom board with nRF Connect SDK v2.6.0, while it was unnecessary for older versions like v2.4.0?

Understanding the underlying reasons would be valuable for further development and troubleshooting.