nRF54L15: Garbled uart21 after bt_enable() when running without SWD

The UART (Port 2) gets garbled after bt_enable(). This issue does not occur if actively Debugging using Segger.

The issue is also reproducible upon a settings_save_one() call. But the UART shell behavior is restored if NRF_POWER->TASKS_CONSTLAT is set to 1.

For the bt_enable() test step, though, the CONSTLATSTAT is set back to 0 constantly so the UART shell remains unrecoverable.

```

4:22:29.4657|[00:?0:11.650,9200m<inf>sys: Event 0x01

14:22:29.4[0?0:11.650,980??1;33m<wrn> led: sequ? 1 in ??ogress, queueing 3

14:22:29.4?--- 24?sages dropped ---

14:22:29.4988|??[00:00:11.?2] nf>?sdc_hci_driv?SoftDevoce Controll?ild??sion: 

14:22:29.5002|    ?    ?                           c7 53 7d bc 06 ?f7 c0  b3 3a?28 8e 56 1e d7S}..... .:>(?

14:22:29.5024|                   ?          ?     a0 be 9 ?                   ?              |....             

14:22:29.5038--- 5 me???s dred ---

14:22:29.5200|[00:00??653,648] <?f> b?i_c? HW Platform: N??dic SemicondReceived kdp CRC

bad packet crc 0x1a0681f != 0x30282072

?essadropped ---

14:22:29.5545|00:00:??3,6?[0m<in bt_hci_co?rmwareStandard Blth c???oller (0x00) Version.32083 Build5153724

14:22:29.5572|-- mes???s dropp?d ---

14:22:29.5741|m[00:00:11.?53,9?<inf> bt_h??_coro Iress. p mu@ call ??ings?d()

14:22:29.5743|uart:~$ 8x8-- 4ssagdropped ---

14:22:29.5911|?00:11.653,927] m<in?le:???tooitialized

```

Parents Reply Children
  • I have the following code:

    // Turning on BLE radio
          err = bt_enable(NULL);
          NRF_POWER->TASKS_CONSTLAT = 1;
          if (err) {
            LOG_ERR("Bluetooth init failed (err %d)\n", err);
            return false;
          }
    
          LOG_INF("Bluetooth initialized\n");
    
          if (IS_ENABLED(CONFIG_SETTINGS)) {
            settings_load();
          }

    I even tried moving the `NRF_POWER->TASKS_CONSTLAT = 1;` to after the settings_load() call and issue still persists.

    I'm still seeing garbled UART:

    14:07:54.2958|[00:00:08.691,791] <inf> bt_sdc_hci_driver: SoftDevice Controller build revision: 
    14:07:54.2995|                                            c7 53 7d bc 06 12 f7 c0  b3 3a 3e 28 8e 56 1e d7 |.S}..... .:>(.V..
    14:07:54.3005|                                            a0 be 95 b0                                      |....             
    14:07:54.3020|[00:00:08.694,266] <inf> bt_hci_core: HW Platform: Nordic Smico??tor 002)
    14:07:54.3021|uart:~ ?p8p8p8p8p8
    14:07:54.8185[00??r?ʢb?<inf>t_hci_core: HW Variant: nRF54Lx (0x0005)
    14:07:5[008.69??1] <inf>?t_hc??re: ?ware: Standa?B?etoo?controllr (0x00) Version 1?83 Bu?? 414????724
    14:07:55.10[0?0:08.694,5?0m<inf?bt_h?_core: No ID addr?ss.?must call s???gs_load()
    14:07:55.1[00 ?08.694,45] <inf> ble:ooth?tialized
    14:07:55.1418|
    

    Is there any way to disallow BLE stack from tampering with the constant latency mode?

Related