Issues migrating from v2.5.0 to v2.9.1

RE: Issues migrating from v2.5.0 to v2.9.1

Maria Gilje — Thu, 19 Jun 2025 11:50:47 GMT

Thank you for your patience.

[quote user="rwahidi"]Still no luck unfortunately, maybe someone can check my custom overlay for compatibility with the hardware model v2? [/quote]

I see that in the HWMv2 board files, gpio-reserved-ranges includes <8, 3>, so &gpio0 8 can't be used.

[quote user="rwahidi"]I tried using the PAN1780_EVB board files, but I receive this error during the build:[/quote]

My apologies for suggesting this. The PAN1780 EVB does not have external flash, so this result is expected when building a Matter application with FOTA functionality.

[quote user="rwahidi"]I forgot to clarify, I never built for the PAN1780 Evalboard. The base configuration is always nrf52840dk/nrf52840.[/quote]

I do recommend that you build the application with your board as the target. This way you are sure that the firmware is meant for the board hardware.

Since you don't build for your board, am I right to assume that you don't have board files for your custom board? These can be created through our nRF Connect for VS Code extension. Since your board is quite similar to the nRF52840 DK, you should be able to use the board files for the DK as a reference when populating the generated board files with relevant configurations.

Lesson 3 in the nRF Connect SDK Intermediate course also covers adding custom board support.

Best regards,

Maria

RE: Issues migrating from v2.5.0 to v2.9.1

rwahidi — Wed, 11 Jun 2025 16:02:30 GMT

I forgot to clarify, I never built for the PAN1780 Evalboard. The base configuration is always nrf52840dk/nrf52840. I just have an overlay file that maps some IO's differently for my custom boards, but this is not in use right now so it can be ignored.

So if I build the unmodified light bulb sample, these are my observations:

In SDK v2.5 I can take the same hex file and flash it to the nRF52840-DK and my PAN1780. Both of them will boot and have a BLE beacon.
In SDK v2.9.1 flashing the hex file boots on the nRF52840-DK but does not work on the PAN1780

I tried using the PAN1780_EVB board files, but I receive this error during the build:

/home/entwicklung/ncs/v2.9.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h: In function '__flash_area_ids_for_slot':

/home/entwicklung/ncs/v2.9.1/bootloader/mcuboot/boot/zephyr/include/sysflash/pm_sysflash.h:19:60: error: 'PM_MCUBOOT_SECONDARY_ID' undeclared (first use in this function); did you mean 'PM_MCUBOOT_PRIMARY_ID'?

   19 | #define FLASH_AREA_IMAGE_0_SLOTS    PM_MCUBOOT_PRIMARY_ID, PM_MCUBOOT_SECONDARY_ID,

      |                                                            ^~~~~~~~~~~~~~~~~~~~~~~

RE: Issues migrating from v2.5.0 to v2.9.1

Maria Gilje — Thu, 05 Jun 2025 08:43:40 GMT

[quote user="rwahidi"]Do you have any findings on your end?[/quote]

Apologies, I don't have anything yet.

[quote user="rwahidi"]However, the SDK v2.9.1 version of my firmware (and the unmodified light bulb sample) works well on the devkit but does not boot properly on the PAN1780. The Panasonic module uses the nRF-52840 and the same flash memory as the devkit. Building for the standard board files with some overlay changes has worked until now. The blinky sample does not have this problem.[/quote]

This finding that the unchanged light bulb sample does not run on the PAN1780 is interesting. Could you do one (or both) of the following?

Share your PAN1780 overlay and board specific .conf you use for the unchanged light bulb sample.
Build the light bulb sample for both PAN1780 and nRF52840 DK and compare the generated .config files between the two builds.

I took a quick look at the board files for PAN1780 here, but I did not find any obvious nodes missing.

Best regards,

Maria

RE: Issues migrating from v2.5.0 to v2.9.1

rwahidi — Wed, 04 Jun 2025 12:51:51 GMT

Hello Maria,

Thank you for your help. After some testing, I found that SDK v2.5 works fine.

However, the SDK v2.9.1 version of my firmware (and the unmodified light bulb sample) works well on the devkit but does not boot properly on the PAN1780. The Panasonic module uses the nRF-52840 and the same flash memory as the devkit. Building for the standard board files with some overlay changes has worked until now. The blinky sample does not have this problem.

Do you have any findings on your end?

Best regards

RE: Issues migrating from v2.5.0 to v2.9.1

Maria Gilje — Fri, 23 May 2025 09:40:25 GMT

Hello,

Thank you for the update.

I have reproduced this now, and will start debugging. I'll report back with my findings as soon as I have some. I will strive to get back to you by end of Tuesday.

Best regards,

Maria

RE: Issues migrating from v2.5.0 to v2.9.1

rwahidi — Wed, 21 May 2025 15:45:34 GMT

Still no luck unfortunately, maybe someone can check my custom overlay for compatibility with the hardware model v2?

/*
 * Copyright (c) 2021-2022 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 */

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};

	/*
	* In some default configurations within the nRF Connect SDK,
	* e.g. on nRF52840, the chosen zephyr,entropy node is &cryptocell.
	* This devicetree overlay ensures that default is overridden wherever it
	* is set, as this application uses the RNG node for entropy exclusively.
	*/

	chosen {
		zephyr,entropy = &rng;
	};

	/*
	* By default, PWM module is only configured for led0 (LED1 on the board).
	* The light bulb app, however, uses LED2 to show the state of the lighting,
	* including its brightness level.
	*/
	aliases {
		pwm-led0 = &pwm_led0;
		pwm-led1 = &pwm_led1;
	};

	pwmleds {
		pwm_led0: pwm_led_0 {
			pwms = <&pwm0 0 PWM_HZ(1600) 1>;
		};
		//pwm_led1: pwm_led_1 {
		//	pwms = <&pwm1 0 PWM_HZ(1600) 1>;
		//};
	};

};

/ {
    bgt60 {
        compatible = "gpio-keys";
        targetd: d_target {
            gpios =
				<&gpio0 8 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
            label = "Target detection";
        };
        phased: d_phase {
            gpios =
				<&gpio0 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
            label = "Phase detection";
        };
    };
    
    aliases {
        targetd = &targetd;
        phased = &phased;
    };
};


&pwm0 {
	pinctrl-0 = <&pwm0_default_alt>;
	pinctrl-1 = <&pwm0_sleep_alt>;
	pinctrl-names = "default", "sleep";
};

/*&pwm1 {
	pinctrl-0 = <&pwm1_default_alt>;
	pinctrl-1 = <&pwm1_sleep_alt>;
	pinctrl-names = "default", "sleep";
	status="okay";
};*/

/*&pinctrl {
    pwm0_default_alt: pwm0_default_alt {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 0, 27)>;
			bias-pull-down;
        };
    };
 
    pwm0_sleep_alt: pwm0_sleep_alt {
        group1 {
            psels = <NRF_PSEL(PWM_OUT0, 0, 27)>;
            low-power-enable;
        };
    };
 
    pwm1_default_alt: pwm1_default_alt {
        group2 {
            psels = <NRF_PSEL(PWM_OUT0, 0, 26)>;
            //nordic,invert;
			bias-pull-up;
        };
    };
 
    pwm1_sleep_alt: pwm1_sleep_alt {
        group2 {
            psels = <NRF_PSEL(PWM_OUT0, 0, 26)>;
            low-power-enable;
        };
    };

};*/

&pinctrl {
    pwm0_default_alt: pwm0_default_alt {
        group1 {
            psels = <NRF_PSEL(PWM_OUT1, 0, 26)>;
        };
    };
 
    pwm0_sleep_alt: pwm0_sleep_alt {
        group1 {
            psels = <NRF_PSEL(PWM_OUT1, 0, 27)>;
            low-power-enable;
        };
    };
 
};


/* Disable unused peripherals to reduce power consumption */
&adc {
	status = "disabled";
};
&uart1 {
	status = "disabled";
};
&i2c0 {
	status = "okay";
};
&spi1 {
	status = "disabled";
};
&spi3 {
	status = "disabled";
};
&usbd {
	status = "disabled";
};

&i2c0_default {
	group1 {
		psels = <NRF_PSEL(TWIM_SDA, 0, 30)>, <NRF_PSEL(TWIM_SCL, 0, 4)>;
	};
};

&spi0 {
	status = "okay";
	cs-gpios = <&gpio0 16 0>;
};

&spi0_default {
	group1 {
		psels = <NRF_PSEL(SPIM_SCK, 0, 19)>,
				<NRF_PSEL(SPIM_MOSI, 0, 21)>,
				<NRF_PSEL(SPIM_MISO, 0, 20)>;
	};
};

/*&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_TX, 0, 9)>, <NRF_PSEL(UART_RTS, 0, 5)>;
	};

	group2 {
		psels = <NRF_PSEL(UART_RX, 0, 10)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0_sleep {
	group1 {
		psels = <NRF_PSEL(UART_TX, 0, 9)>,
				<NRF_PSEL(UART_RX, 0, 10)>,
				<NRF_PSEL(UART_RTS, 0, 5)>,
				<NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0 {
	current-speed = <115200>;
};*/


&nfct {
	status = "okay";
};

&uart0_default {
	group1 {
		psels = <NRF_PSEL(UART_RTS, 0, 5)>, <NRF_PSEL(UART_TX, 0, 9)>;
	};

	group2 {
		psels = <NRF_PSEL(UART_RX, 0, 10)>, <NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

&uart0_sleep {
	group1 {
		psels = <NRF_PSEL(UART_TX, 0, 9)>,
				<NRF_PSEL(UART_RX, 0, 10)>,
				<NRF_PSEL(UART_RTS, 0, 5)>,
				<NRF_PSEL(UART_CTS, 0, 7)>;
	};
};

RE: Issues migrating from v2.5.0 to v2.9.1

rwahidi — Tue, 13 May 2025 11:53:03 GMT

Okay I have found the line that causes an assert, it is my custom bgt60.cpp file. There is no additional info.

55	    ret = gpio_pin_configure_dt(&td, GPIO_INPUT);
ERROR: Command aborted. See the output window for additional details.

RE: Issues migrating from v2.5.0 to v2.9.1

rwahidi — Wed, 07 May 2025 08:46:41 GMT

Hello,

the unchanged sample works as expected and can be commissioned.

I have modified the apptask.cpp and I have created a new file BGT60.cpp/BGT60.h with functions related to the sensor. This was functional in SDK v2.5.0. After porting these changes to the new SDK and getting rid of the building errors, the board seems to be stuck in some state.

I have edited the original post to include the full apptask.cpp and related functions.

While debugging, stepping over the initialization function of the Sensor bgt60.init() causes the same IRQ lock. So my best guess is that some of the GPIO configures or interrupts are faulty.

Thank you and best regards,

Wahidi

RE: Issues migrating from v2.5.0 to v2.9.1

Maria Gilje — Tue, 06 May 2025 13:10:09 GMT

Hello,

Can you share the necessary steps to reproduce this? Your shared code does not have all the needed definitions. So far I have added the occupancy cluster in ZAP tool, but since I am missing definitions for several objects and functions in AppTask.cpp, I'm not able to build the project.

Just as a sanity check: does the unchanged light bulb sample boot properly?

Best regards,

Maria