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

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?

Parents
  • 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.

  • # 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.

Reply
  • # 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.

Children
No Data
Related