Simple project working with zephyr v4.3.0 is not working with latest zephyr

[Paul Vogel0]

I have a simple project running on a custom board with a nrf54L10 processor.  The board has a couple of LEDs to blink and advertises on BLE.  With v4.3.0, the LED blinks for 50ms once per second.  I am able to see the device advertise and I can connect and interact with it,

I updated to the latest zephyr (hash  81c77d59d12c46) to see if a different issue with the board had been resolved.  However, building/flashing the application results in the LED being on almost continuously, sort flickering and occasionally blinking.  The device still seems to be advertising, but as soon as I try to connect to it, it immediately disconnects.

The code does a bt_enable() followed by a bt_le_adv_start().  The application LED blinks normally if just the bt_enable is called (skipping the advertising start).  However, if the bt_le_adv_start is called, it succeeds but the LED no longer blinks normally.

Doing a git bisect resulted in this being the first bad commit:

145e0d75e37a6a6827ad06886e168d4618c94c54 is the first bad commit
commit 145e0d75e37a6a6827ad06886e168d4618c94c54
Author: Michał Stasiak <[email protected]>
Date: Mon Jan 26 10:32:55 2026 +0100

manifest: update hal_nordic revision to integrate nrfx 4.1.0

Updated hal_nordic manifest and trusted-firmware-m manifest
with alignment.

Signed-off-by: Michał Stasiak <[email protected]>

dts/arm/nordic/nrf54lm20_a_b_cpuapp.dtsi | 147 ++++
dts/arm/nordic/nrf54lm20a_cpuapp.dtsi | 8 +
dts/arm/nordic/nrf54lm20a_enga_cpuapp.dtsi | 147 ----
dts/riscv/nordic/nrf54lm20_a_b_cpuflpr.dtsi | 68 ++
dts/riscv/nordic/nrf54lm20a_cpuflpr.dtsi | 8 +
dts/riscv/nordic/nrf54lm20a_enga_cpuflpr.dtsi | 68 --
dts/vendor/nordic/nrf54lm20_a_b.dtsi | 929 +++++++++++++++++++++
.../nordic/nrf54lm20_a_b_cpuapp_ns_partition.dtsi | 91 ++
.../nordic/nrf54lm20_a_b_cpuapp_partition.dtsi | 37 +
dts/vendor/nordic/nrf54lm20a.dtsi | 924 +-------------------
.../nordic/nrf54lm20a_cpuapp_ns_partition.dtsi | 85 +-
dts/vendor/nordic/nrf54lm20a_cpuapp_partition.dtsi | 32 +-
west.yml | 4 +-
13 files changed, 1293 insertions(+), 1255 deletions(-)
create mode 100644 dts/arm/nordic/nrf54lm20_a_b_cpuapp.dtsi
create mode 100644 dts/arm/nordic/nrf54lm20a_cpuapp.dtsi
delete mode 100644 dts/arm/nordic/nrf54lm20a_enga_cpuapp.dtsi
create mode 100644 dts/riscv/nordic/nrf54lm20_a_b_cpuflpr.dtsi
create mode 100644 dts/riscv/nordic/nrf54lm20a_cpuflpr.dtsi
delete mode 100644 dts/riscv/nordic/nrf54lm20a_enga_cpuflpr.dtsi
create mode 100644 dts/vendor/nordic/nrf54lm20_a_b.dtsi
create mode 100644 dts/vendor/nordic/nrf54lm20_a_b_cpuapp_ns_partition.dtsi
create mode 100644 dts/vendor/nordic/nrf54lm20_a_b_cpuapp_partition.dtsi

[Vidar Berg]

Hello,

Using vanilla Zephyr, I updated to the same hash which includes nrfx 4.1.0, and tested the peripheral_hr sample using the nrf54l15dk/nrf54l10/cpuapp build target on a nRF54l15 DK board, but I did not observe the issues you described.  The LED blinks while advertising, and I was also able to establish a BLE connection without any problems. I also can't think of anything that could cause the LEDs to flicker. For the connection issues we would also need more debug information such as the disconnect reason reported in the disconnected callback.

Have you considered using our nRF Connect SDK which includes our qualified Bluetooth controller (https://docs.nordicsemi.com/bundle/comp_matrix_nrf54l10/page/COMP/nrf54l10/nrf54l10_ble_qdid_qual_matrix.html)?

Best regards,

Vidar

[Paul Vogel0]

Thanks for info.  It didn't look like there was anything in that commit that should have affect BT or the nrf5410, but it may have been a change in the associated changes when the "west update" for with that hash was done.

The BLE controller hasn't been an issue for us.  The reason I was trying to go to a later version of Zepyhr is due to a problem receiving data reliably on a UART from a GNSS devices.  I've been working through this on the Zephyr forum and got a reference to this

https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/drivers/uart.html#reliable_reception_on_nrf54l_and_nrf54h_series

which says to add a "timer" property to the uart node in the devicetree.  This property was not supported in the version of Zephyr that I was using, so I updated to the latest and did the west update.  I saw the issue with the LEDs and BLE with it, so I did the "git bisect" between the latest (which failed) and the v4.3.0 (which did not have the LED / BLE issue).

I'm still testing the UART data from GNSS with the suggestions from the above link, but so far, nothing has worked.  In  that case, the update to the latest Zephyr may not be of any use anyway.

[Vidar Berg]

I see thanks for the update. Maybe you could create another ticket here for the UART issues you are experiencing. It is also important to have the HF crystal oscillator active while having the UART receiver enabled to ensure the baud rate is sufficiently stable and accurate across devices and temperature.

[Paul Vogel0]

OK, I will also create a ticket for the UART issue.  Thanks for the update!

[Paul Vogel0]

Just FYI, I created the ticket for the UART - 357607