nRF54L10 ESB runtime configuration switch issue with data whitening on NCS v3.0.0

[Alex]

**Environment:**
- NCS Version: v3.0.0
- Device: nRF54L10 (PRX role)
- Protocol: ESB (Enhanced ShockBurst)

**Issue Description:**
PRX fails to pair with TYPE2-PTX (no ACK received on PTX) after dynamically switching configuration from TYPE1 to TYPE2.
- Sequence 1: Boot -> TYPE2 Mode -> TYPE2 Pairing: OK
- Sequence 2: Boot -> TYPE1 Mode -> TYPE1 Pairing: OK
- Sequence 3 (Problematic): Boot -> TYPE1 Mode -> Switch to TYPE2 Mode -> TYPE2 Pairing: FAILS (no ACK). If switched back to TYPE1 Mode, TYPE1 Pairing works again.

**Configurations:**
- TYPE1 Config:
- whiteen: true
- s0len: 1
- big_endian: false
- use_fast_ramp_up: true
- channel: [PAIRING_CHANNEL]
- ack_mask: 0xFF
- TYPE2 Config:
- whiteen: false
- s0len: 0
- big_endian: true
- use_fast_ramp_up: false
- channel: [PAIRING_CHANNEL]
- ack_mask: 0xFF

**Observations & Debugging done:**
1. If `whiteen = true` in TYPE1 is disabled/commented out, alternating between TYPE1 and TYPE2 scanning allows TYPE2-PTX to pair successfully.
2. Verified that `NRF_RADIO->PCNF1.WHITEEN` reads `0` (Disabled) after switching to TYPE2, but pairing still fails.

**Questions:**
1. Does the ESB driver in NCS v3.0.0 leave any RADIO hardware registers (such as CRCCNF.SKIPADDR, DATAWHITE, or PCNF0/PCNF1 fields) improperly restored when reinitializing/switching between whitened and non-whitened modes?
2. What is the recommended procedure to completely reconfigure packet format (endianness, s0len, whitening, fast ramp-up) on nRF54L10 at runtime?

[Alex]

After TYPE2 pairing fails, the ESB configuration remains identical to the configuration when TYPE2 pairing succeeds exclude DATAWHITE.
The ESB configuration is as follows，and is same to the define value:
[00:39:38.268,303] <inf> esb_msg_scan: pair msg: 0x4E784AD1,0x4E784AD1, size:28, role:5,5 state:0x81,in-0x1
[00:39:38.348,159] <err> esb: ESB REG: MODE=0x3 FREQ=0x50 PCNF0=0x00030006 PCNF1=0x01040020[whiteen=0 endian=1 balen=4 maxlen=32] DATAWHITE=0x89004A CRCCNF=0x2
[00:39:38.348,168] <err> esb: ESB ADDR: BASE0=0x12345678 BASE1=0x0FA091B3 PREFIX0=0x2ACA4AE7 PREFIX1=0x1BEA6BEE TXADDR=0 RXADDRS=0x01 TXPOWER=0x18
[00:39:38.348,175] <err> esb: ESB CFG: proto=1 rate=3 mode=1 plen=32 s0len=0 whiteen=0 big_endian=1
[00:39:38.354,238] <err> esb: ESB REG: MODE=0x3 FREQ=0x50 PCNF0=0x00030006 PCNF1=0x01040020[whiteen=0 endian=1 balen=4 maxlen=32] DATAWHITE=0x890040 CRCCNF=0x2
[00:39:38.354,247] <err> esb: ESB ADDR: BASE0=0x12345678 BASE1=0x0FA091B3 PREFIX0=0x2ACA4AE7 PREFIX1=0x1BEA6BEE TXADDR=0 RXADDRS=0x01 TXPOWER=0x13
[00:39:38.354,254] <err> esb: ESB CFG: proto=1 rate=3 mode=1 plen=32 s0len=0 whiteen=0 big_endian=1

[Maria Gilje]

Hello, 

Thank you for your inquiry. We will investigate and report back with our findings. Thank you for your patience. 

Best regards,

Maria

[Kenneth]

Hello,

1. I am not quite sure what changes you have done here, but make sure you check the return value of all esb api() calls. I suspect some of the calls are returning error codes here.

2. Also, you can find in the datasheet of the nRF54L10 the default register values of the radio and other peripherals if you are uncertain of what they should be by default.

3. Also to compare the hardware configuration you can do the following:

Read out all registers for the following situations to compare

3.1 Boot -> Type1

3.2 Boot -> Type2

3.3 Boot -> Type1 -> Type2

3.4 Boot -> Type2 -> Type1

You can read out by running: python .\read_global_registers.py --all

To store the output to a file call: python .\read_global_registers.py --all > file1.txt  

nrf54l10_application.zip

Then you can for instance compare 3.2 vs. 3.3 and 3.1 vs. 3.4.

Kenneth