Problem on nRF9160 making a modified lte_ble_gateway sample

Our application on a nRF9160 to act as intermediary between an AWS cloud and another nRF devicee over bluetooth.  So I attempted to merge the bluetooth IOT sample with the bluetooth portion lte_ble_gateway sample

When I tried running this I got this crash in the early portion of the bluetooth intialization, before any IOT code is running. 

[00:00:00.251,251] <inf> health_hub: The AWS IoT sample started, version: v1.0.0
[00:00:00.251,281] <inf> hp_ble: Initializing Bluetooth..
ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:338
command opcode 0x0c03 timeout with err -11
[00:00:10.251,617] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000000 r2/a3: 0x00000002
[00:00:10.251,647] <err> os: r3/a4: 0x20011498 r12/ip: 0x00000010 r14/lr: 0x00020a35
[00:00:10.251,647] <err> os: xpsr: 0x41000000
[00:00:10.251,678] <err> os: Faulting instruction address (r15/pc): 0x00020a40
[00:00:10.251,708] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:10.251,739] <err> os: Current thread: 0x20014010 (unknown)
*** Booting nRF Connect SDK v2.5.1 ***Resetting system

    net_buf_put(&bt_dev.cmd_tx_queue, net_buf_ref(buf));

    err = k_sem_take(&sync_sem, HCI_CMD_TIMEOUT);
    BT_ASSERT_MSG(err == 0, "command opcode 0x%04x timeout with err %d", opcode, err);
Somewhere in the k_sem_take()  we get that error 11 but it isn't clear what it is looking for at that point and stepping in doesn't work well.
Any ideas of what sort of problem can give this error?

Here is the prj.conf in case this is a missing configuration problem or something

#
# Copyright (c) 2020 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#
#CONFIG_DEBUG=y

# General
CONFIG_LOG=y
CONFIG_LOG_BUFFER_SIZE=2048
CONFIG_HW_ID_LIBRARY=y
CONFIG_ASSERT=y
CONFIG_JSON_LIBRARY=y

# Heap and stacks
#CONFIG_HEAP_MEM_POOL_SIZE=8192
#CONFIG_MAIN_STACK_SIZE=4096
#CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

#CONFIG_BOOTLOADER_MCUBOOT=y

# Network
CONFIG_NETWORKING=y
CONFIG_NET_NATIVE=y
CONFIG_NET_IPV4=y
CONFIG_NET_CONNECTION_MANAGER=y

# AWS IoT library
CONFIG_AWS_IOT=y
CONFIG_AWS_IOT_CLIENT_ID_STATIC="my-thing"
CONFIG_AWS_IOT_BROKER_HOST_NAME="xxx.amazonaws.com"
CONFIG_AWS_IOT_SEC_TAG=201
CONFIG_AWS_IOT_APP_SUBSCRIPTION_LIST_COUNT=2
CONFIG_AWS_IOT_TOPIC_UPDATE_DELTA_SUBSCRIBE=y
CONFIG_AWS_IOT_TOPIC_GET_ACCEPTED_SUBSCRIBE=y
CONFIG_AWS_IOT_TOPIC_GET_REJECTED_SUBSCRIBE=y
CONFIG_AWS_IOT_LAST_WILL=y

# MQTT - Maximum MQTT keepalive timeout specified by AWS IoT Core
CONFIG_MQTT_KEEPALIVE=1200
CONFIG_MQTT_CLEAN_SESSION=y

# Console for user association
CONFIG_CONSOLE_SUBSYS=y
CONFIG_CONSOLE_GETCHAR=y

# Enable Bluetooth stack and libraries
CONFIG_BT=y
CONFIG_BT_H4=y
CONFIG_BT_WAIT_NOP=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_GATT_DM=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1

CONFIG_UART_INTERRUPT_DRIVEN=y

# Heap and stacks
CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_MAIN_STACK_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096

# Update Data Length and MTU (BT_L2CAP_RX_MTU = CONFIG_BT_BUF_ACL_RX_SIZE - BT_L2CAP_HDR_SIZE)
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=247


#================================================
# Little FS
#
# Optionally force the file system to be recreated
# CONFIG_APP_WIPE_STORAGE=y


# Let __ASSERT do its job
CONFIG_DEBUG=n

#CONFIG_FLASH=n
#CONFIG_FLASH_MAP=n
#CONFIG_FLASH_PAGE_LAYOUT=n

CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y

# CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y

CONFIG_NVS=y
CONFIG_SETTINGS=y

  • It looks like I was using the other lpuart example instead of hci_uart.

    When I loaded that, the lte_gateway sample i had also ran, at least to the extend of doing a scan.  There wasn't much feedback there but it did display a cryptic message when I turned on the matching bluetooth device.

    However, when I returned to my modified aws_iot app with the bluetooth code in it, I still got the early connection error from above.  Is there something different about this sample from the lte_gateway and its setup?

  • ASSERTION FAIL [err == 0] @ WEST_TOPDIR/zephyr/subsys/bluetooth/host/hci_core.c:338
    command opcode 0x0c03 timeout with err -11

    If you are thinking of this error, this one simply means that the host wasn't able to communicate with the controller over the serial interface, could be some electrical connection problem, hardware flow control, baudrate or wrong pin configuration etc. Maybe some of the pins used have been reconfigured to something else. If you have a logic analyzer you might potentially check working and non-working in case you can see if something is clearly missing.

    Kenneth

  • OK, but I took the gateway example and loaded the version of the controller you suggested and this error did not occur.  So that should eliminate those sorts of errors unless the two examples have different pins or something.

    The merged aws_iot example with the gateway examples bluetooth code still shows that error.  Why would this be if the new lp executable fixed it for the other sample?

    does the aws_iot example require the low power controller program loaded?  

  • I  ran the base IOT and did not get the error, it attempted connection.  What in the set up of the bluetooth gateway bluetooth code am I missing in my combined example?

  • I don't know, but you may compare the output files for the two projects to try to compare, ref:

    \build\zephyr\zephyr.dts
    \build\zephyr\.config

    If you can't find anything you can try to share the output files for the two projects also, and I can try to take a look.

    Kenneth

Related