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
  • Hello,

    Your observation is correct. 

    In Constant Latency mode, the CPU wakeup latency and the PPI task response are constant and kept at a minimum. This is secured by forcing a set of basic resources to be turned on while in sleep mode. UART on Port 2 requires high speed pins which requires constant latency.  So, Port 2 pins work propelry when NRF_POWER->TASKS_CONSTLAT = 1 is set.

    However, after certain operation ( bt_enable() ), the application or BLE stack may go back to low power mode, which triggers disabling constant latency and causes UART on port2 not functions properly. That's why you need to reenable constant latency.

    bt_enable(...);
    // need to set constant latency right after bt_enable()
    NRF_POWER->TASKS_CONSTLAT = 1;

    You can read this previous case (17) [nrf54L15-PDK] Trying to use pin2.07 & pin2.08 with UARTE instance uart21, but get framing error - Nordic Q&A - Nordic DevZone - Nordic DevZone

    Thanks.

    BR

    Kazi

  • 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?

Reply
  • 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?

Children
No Data
Related