lte_ble_gateway fails with NCS 2.2 and thingy:91 rev 1.6.0


Hi!

I am building an application that is based on the lte_ble_gateway which works perfectly on the nrf9160dk. However, it does not work on the thingy:91.
The error is also present in the unmodified lte_ble_gateway sample, so it should be easy to reproduce.

I am trying to run lte_ble_gateway to a thingy:91 rev 1.6.0, but get the following error message when running the application:
** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.487,274] <inf> lte_ble_gw: LTE Sensor Gateway sample started
[00:00:00.487,426] <inf> lte_ble_gw: Initializing Bluetooth..
[00:00:00.504,943] <inf> lte_ble_gw: Establishing LTE link (this may take some time) ...
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:329
k_sem_take failed with err -11
[00:00:10.497,924] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x00000002
[00:00:10.497,955] <err> os: r3/a4: 0x2000e168 r12/ip: 0x20016e78 r14/lr: 0x000223b3
[00:00:10.497,955] <err> os: xpsr: 0x41000000
[00:00:10.497,985] <err> os: Faulting instruction address (r15/pc): 0x000223be
[00:00:10.498,016] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:10.498,046] <err> os: Current thread: 0x2000eea0 (unknown)
[00:00:10.720,733] <err> fatal_error: Resetting system

Output from nrf52840:
*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.000,671] <inf> sdc_hci_driver: SoftDevice Controller build revision:
6d 90 41 2a 38 e8 ad 17 29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
1f 85 d8 e1 |....
[00:00:00.001,312] <inf> bt_hci_raw: Bluetooth enabled in RAW mode
[00:00:01.001,373] <wrn> lpuart: Tx timeout
[00:00:02.002,166] <wrn> lpuart: Tx timeout
[00:00:03.002,990] <wrn> lpuart: Tx timeout
[00:00:04.003,814] <wrn> lpuart: Tx timeout
[00:00:05.004,638] <wrn> lpuart: Tx timeout
[00:00:06.005,462] <wrn> lpuart: Tx timeout
*** Booting Zephyr OS build v3.2.99-ncs1 ***
[00:00:00.000,671] <inf> sdc_hci_driver: SoftDevice Controller build revision:
6d 90 41 2a 38 e8 ad 17 29 a5 03 38 39 27 d7 85 |m.A*8... )..89'..
1f 85 d8 e1 |....
[00:00:00.001,312] <inf> bt_hci_raw: Bluetooth enabled in RAW mode

I build lte_ble_gateway with the command:
west build --board thingy91_nrf9160_ns@1.6.0

and hci_lpuart:
west build --board thingy91_nrf52840@1.6.0

I have managed to get the sample working for the nrf9160DK earlier (Where I had to build with west build --board nrf9160dk_nrf52840@1.1.0 for hci_lpuart and nrf9160dk_nrf9160_ns@1.1.0 for lte_ble_gateway)

I have looked at this post, but it is not an option to downgrade to NCS 1.9.X: devzone.nordicsemi.com/.../382953

Additionally, it is really tidious to debug as the flashing process fails 70% of the time and the nrf9160dk disappears from discovered devices, which means that I must reboot my computer. Any tips on this would also be greatly appreciated.

Thanks in advance for your help.

Parents
  • Hi,

    You could try to disable UART for MCUboot. To do this you could add an overlay file mcuboot.overlay in the child image folder for both hci_lpuart and lte_ble_gateway.

    Fullscreen
    1
    2
    3
    4
    5
    6
    &uart1 {
    /delete-property/ rts-pin;
    /delete-property/ cts-pin;
    /delete-property/ hw-flow-control;
    status = "disabled";
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Best regards,
    Dejan

  • Unfortunately, that doesn't seem to solve the issue. I also get these warnings when compiling if it is relevant:

    HCI_LPUART:
    warning: BT_CTLR_DTM_HCI (defined at subsys/bluetooth\controller\Kconfig.dtm:14) was assigned the
    value 'y' but got the value 'n'. Check these unsatisfied dependencies: BT_CTLR_DTM_HCI_SUPPORT (=n).
    See docs.zephyrproject.org/.../kconfig.html and/or look up
    BT_CTLR_DTM_HCI in the menuconfig/guiconfig interface. The Application Development Primer, Setting
    Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
    too.

    warning: BOOTLOADER_MCUBOOT (defined at C:/Users/jonat/ncs/v2.2.0/nrf/modules/trusted-firmware-m/Kconfig:178, Kconfig.zephyr:745) was assigned the value 'y' but got the value 'n'. Check
    these unsatisfied dependencies: (BUILD_WITH_TFM || !MCUBOOT) (=n). See
    docs.zephyrproject.org/.../kconfig.html and/or look up
    BOOTLOADER_MCUBOOT in the menuconfig/guiconfig interface. The Application Development Primer,
    Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
    helpful too.

    LTE_BLE_GATEWAY:
    CMake Warning at C:/Users/jonat/ncs/v2.2.0/zephyr/cmake/modules/boards.cmake:127 (message):
    Board revision 1.6.0 specified for thingy91_nrf9160, but board has no
    revision so revision will be ignored.
    Call Stack (most recent call first):
    C:/Users/jonat/ncs/v2.2.0/zephyr/cmake/modules/zephyr_default.cmake:108 (include)
    C:/Users/jonat/ncs/v2.2.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
    C:/Users/jonat/ncs/v2.2.0/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
    CMakeLists.txt:44 (find_package)

  • Please check if the firmware on the nRF9160 enters this function and reaches the gpio_pin_set() call during startup to reset the nRF52840: https://github.com/nrfconnect/sdk-nrf/blob/50e2c516fb37a0a8f26558f419fe3510d02375e5/boards/arm/thingy91_nrf9160/nrf52840_reset.c#L41. You can do so by placing a breakpoint in this function.

    Thanks,

    Vidar 

  • Hi,

    I updated the SDK to 2.5.99 which seemed to do the trick.

    Now I have a new issue regarding the thingy refusing to establish LTE connection (it worked yesterday, but stopped working after updating the modem FW). But I assume that is for another ticket.

    Thanks for your support.

    -Jonathan

  • Hi Jonathan,

    It may be a good idea to try with v2.5.0 instead. The main branch is continuously updated and may not always be stable. If you continue to experience issues with your LTE connection, I recommend creating a new support ticket.

    Vidar

  • Hi,

    I also use a Thingy91 and I'm trying to test the Bluetooth.
    I have the same setup (ncs V2.5.1), 'hci_lpuart' sample on the nrf52840 and 'lte_ble_gateway' on the nrf9160 (NS).

    My nRF9160 logs:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    *** Booting nRF Connect SDK v2.5.1 ***
    [00:00:00.257,415] \033[0m<inf> lte_ble_gw: LTE Sensor Gateway sample started\033[0m
    [00:00:00.257,568] \033[0m<inf> lte_ble_gw: Initializing Bluetooth..\033[0m
    [00:00:00.271,148] \033[1;33m<wrn> lpuart: req pin low when expected high\033[0m
    [00:00:00.271,270] \033[1;31m<err> lpuart: Empty receiver state:4\033[0m
    [00:00:00.502,441] \033[0m<inf> lte_ble_gw: Establishing LTE link (this may take some time) ...\033[0m
    [00:00:01.363,311] \033[1;31m<err> lpuart: Empty receiver state:4\033[0m
    ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:338
    command opcode 0x0c03 timeout with err -11
    [00:00:10.268,066] \033[1;31m<err> os: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x00000002\033[0m
    [00:00:10.268,066] \033[1;31m<err> os: r3/a4: 0x2000d298 r12/ip: 0x00000010 r14/lr: 0x0002049d\033[0m
    [00:00:10.268,096] \033[1;31m<err> os: xpsr: 0x41000000\033[0m
    [00:00:10.268,096] \033[1;31m<err> os: Faulting instruction address (r15/pc): 0x000204a8\033[0m
    [00:00:10.268,157] \033[1;31m<err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0\033[0m
    [00:00:10.268,188] \033[1;31m<err> os: Current thread: 0x2000f7b8 (unknown)\033[0m
    [00:00:10.490,264] \033[1;31m<err> fatal_error: Resetting system\033[0m
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    and my nRF52840 logs:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    *** Booting nRF Connect SDK v2.5.1 ***
    [00:00:00.726,226] \033[0m<inf> bt_sdc_hci_driver: SoftDevice Controller build revision:
    c5 93 ba a9 14 4d 8d 05 30 4e 9b 92 d7 71 1e e8 |.....M.. 0N...q..
    aa 02 50 3c |..P< \033[0m
    [00:00:00.726,593] \033[0m<inf> bt_hci_raw: Bluetooth enabled in RAW mode\033[0m
    [00:00:01.726,623] \033[1;33m<wrn> lpuart: Tx timeout\033[0m
    [00:00:02.727,478] \033[1;33m<wrn> lpuart: Tx timeout\033[0m
    [00:00:03.728,302] \033[1;33m<wrn> lpuart: Tx timeout\033[0m
    [00:00:04.729,125] \033[1;33m<wrn> lpuart: Tx timeout\033[0m
    [00:00:05.729,949] \033[1;33m<wrn> lpuart: Tx timeout\033[0m
    [00:00:06.730,773] \033[1;33m<wrn> lpuart: Tx timeout\033[0m
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    What's wrong with my configuration?
    I didn't change anything in these samples, I just copied, compiled and flashed.

    Thanks,
    Dorian

  • Now I am also getting the same error as Dorian

Reply Children
  • The crashlog suggests that the Host running on the 9160 is unable to communicate with the BT controller on the nRF52840, which could indicate an issue with the pin connections between the devices.  

    Jonathan E said:
    Now I am also getting the same error as Dorian

    Are you seeing the same lpuart warnings/errors on startup as Dorian? Also, do you happen to still have the generated zephyr.dts from your working build so you can compare the pin configurations?

  • I removed CONFIG_GPIO_AS_PINRESET earlier as I got a warning about it being deprecated and I think that is what caused the exact same error messages as Dorian had. I added it again and it started working again.

  • Thanks for the update. This probably explains why the 91 failed to syncronize with the controller.

    The CONFIG_GPIO_AS_PINRESET option has been deprecated and will eventually be removed, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.1/zephyr/releases/migration-guide-3.5.html#recommended-changes 

  • Try adding

    CONFIG_GPIO_AS_PINRESET=y

    I tested: no changes.

    I already have this in thingy_nrf52840.overlay. So there is no need of CONFIG_GPIO_AS_PINRESET?

    Fullscreen
    1
    2
    3
    &uicr {
    gpio-as-nreset;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I've just re-downloaded the latest version of the samples.

    which could indicate an issue with the pin connections between the devices

    Dts misconfiguration or hardware ? I use the thingy91, so I don't think is a hardware problem.

    Here you can find my zephyr.dts of my nRF52840:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /dts-v1/;
    / {
    #address-cells = <1>;
    #size-cells = <1>;
    model = "Nordic Thingy91 NRF52840";
    compatible = "nordic,thingy91-nrf52840";
    chosen {
    zephyr,entropy = &cryptocell;
    zephyr,flash-controller = &flash_controller;
    zephyr,console = &uart0;
    zephyr,flash = &flash0;
    zephyr,sram = &sram0;
    zephyr,uart-mcumgr = &uart0;
    zephyr,bt-c2h-uart = &lpuart;
    };
    aliases {
    mcuboot-button0 = &button0;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Many thanks,

    Dorian

  • Hi Dorian, 

    I meant a misconfiguration of the DT. I don't expect it to be a HW issue. Where did you find the zephyr.dts file you posted? The reason I'm asking is that it doesn't look like a DTS file typically generated during a build.