How to debug nRF52840 and nRF9160 designs on Thingy:91 board

[bojan]

Hi guys!

I am witnessing the things are evolving pretty fast around Thingy:91! What was up-to-date and actual yesterday is outdated today! That's why I would like to ask some fresh questions about some things...

1. We were recently forced to move from 1.1.0 tag to master branch because we wanted to benefit from cloud_client example and connection with AWS IoT Cloud. In that master branch, we were unfortunately unable to debug our nRF9160/nRF52840 designs from Segger Embedded Studio, according to this thread. I see that there is a tag 1.2.0 available now. Is it possible to debug with SES from tag 1.2.0or from master?
2. How can we keep nRF52840 as a nRF9160 controller/debugger and add some BLE functionality over that usb_uart_bridge? I can see some threads discussing about that(e.g. here) but I am unable to benefit from them because we are now in master branch and it's impossible to apply fixes and patches suggested for 1.1.0 tag. It is too bad that nRF52840 is used only as nRF9160 controller with so much troubles and efforts needed to add some basic BLE functionality.
3. We need only to read advertisement messages from some Bluetooth beacons with known UUIDs. Can you reference me to some similar example?

Thanks in advance for your time and efforts!

Sincerely,

Bojan.

[bojan]

Sigurd, Heidi, I need your help, guys. We are hitting the wall and are unable to advance in our development since we are unable to debug our designs and benefit from nRF52840 BLE services on Thingy:91 board at the same time.

Heidi, is it possible to debug with SES on branches 1.2.0 or master?

Sigurd, we were forced to move from the 1.1.0 tag to 1.2.0 or master because we need cloud_client example and communication with AWS IoT Cloud. I was unable to apply your R2 patches from here for hci_uart_with_usb_uart_bridge example on  1.2.0 or master. Any suggestion how can I do it?

Thanks in advance, guys, for your time and efforts.

Sincerely,

Bojan.

[Sigurd]

Hi,

1) SES debugging: There are issues with debugging with both SES v4.42a and 4.30c. The bugs has been reported internally, and we are working on a solution.
Most likely we will release an updated version of SES. Note that a workaround for 4.30c is to set Project "zephyr/zephyr.elf" as active project. But, for the moment, I recommend using Segger Ozone instead of SES for debugging: https://www.segger.com/products/development-tools/ozone-j-link-debugger/

2) My patch is made for NCS v1.1.0, I have not done a NCS v1.2.0 patch, but in the meantime you can try to add the changes manually by looking at the patch-files.

3) Maybe you can take a look at the central_uart sample, and see how the UUID filtering is done there. 

[bojan]

Hi, Sigurd.

Thanks for your reply and useful info shared! I will focus on point 2) now...

I tried to implement the patches manually by following the differences within nrf.patch and zephyr.patch files.

I think the project lte_ble_gateway is successfully patched because it is working either when I build and download .hex file from SES or when I use .hex file you shared.

I think something is wrong with hci_uart_with_usb_uart_bridge project though! When I use .hex file you provided, I am able to use LTE Link Monitor and debug. When I compile the project from SES and download generated .hex file, I can't see Thingy board on LTE Link Monitor!

I also used the following west commands to build and flash Thingy:91 board but with no success (Thingy:91 board still invisible through LTE Link Monitor):

west build -b nrf52840_pca20035 -d build
west flash -d build

What I noticed while compiling hci_uart_with_usb_uart_bridge project are two warnings about deprecated macros:

NET_BUF_POOL_DEFINE(cmd_tx_pool, CONFIG_BT_HCI_CMD_COUNT, CMD_BUF_SIZE,
		    BT_BUF_USER_DATA_MIN, NULL);
		    
NET_BUF_POOL_DEFINE(acl_tx_pool, TX_BUF_COUNT, BT_BUF_ACL_SIZE,
		    BT_BUF_USER_DATA_MIN, NULL);		    

Could that be an issue stopping Thingy:91 to be visible?

I also needed to comment the following two lines of lte_ble_gateway prj.conf file because otherwise I was unable to load the project into SES:

#CONFIG_CLOUD_UA_BUTTONS=n
#CONFIG_CLOUD_UA_CONSOLE=n

Also, can you tell me what is the purpose of that Reset pin coming from nRF9160 to nRF52840? Do you use it to reset nRF52840 during start-up process or to keep the nRF52840 SoC in reset state until the moment you want to receive some BLE data?

Thanks in advance for your help. It is appreciated as always!

Sincerely,

Bojan.

[bojan]

Hello, Sigurd.

I wanted to add usb_uart thread to the bluetooth central_uart example the similar way you did in hci_uart_with_usb_uart_bridge project. Now, to the best of my understanding, reset pin (P20) in hci_uart_with_usb_uart_bridge project serves to keep nRF52840 in reset state until all bytes on h4 lines are received and drained correctly. That's why you keep reset pin HIGH until:

	while (uart_fifo_read(h4, &c, 1)) {
		continue;
	}

To the best of my understanding, again, I think I don't need to keep nRF52840 in reset state in central_uart example. nRF9160 and nRF52840 are interconnected through MCU_IF[7:0] pins where, by default (in common.dts files) &uart1 and &uart0 interfaces are placed. So my first guess was just to add usb_uart thread from your example to central_uart example. I did it and the compilation passed successfully. However, I was unable to see PCA20035 board from LTE Monitor app. Here is how my prj.conf file looks like:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-BSD-5-Clause-Nordic
#
CONFIG_NCS_SAMPLES_DEFAULTS=y

# Enable the UART driver
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_SERIAL=y
CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y
CONFIG_UART_0_NRF_FLOW_CONTROL=y

# Enable the BLE stack with GATT Client configuration
CONFIG_BT=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_SMP=y
CONFIG_BT_GATT_CLIENT=y

# Enable the BLE modules from NCS
CONFIG_BT_GATT_NUS_C=y
CONFIG_BT_SCAN=y
CONFIG_BT_SCAN_FILTER_ENABLE=y
CONFIG_BT_SCAN_UUID_CNT=1
CONFIG_BT_GATT_DM=y
CONFIG_HEAP_MEM_POOL_SIZE=2048

# This example requires more workqueue stack
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

# Enable bonding
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y

 # USB
CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_MANUFACTURER="Nordic Semiconductor"
CONFIG_USB_DEVICE_PRODUCT="Thingy:91 UART"
CONFIG_USB_DEVICE_VID=0x1915
CONFIG_USB_DEVICE_PID=0x520F
CONFIG_USB_DEVICE_SN="PCA20035 12PLACEHLDRS"
CONFIG_USB_COMPOSITE_DEVICE=y
CONFIG_USB_CDC_ACM=y
CONFIG_USB_CDC_ACM_RINGBUF_SIZE=4096
CONFIG_USB_CDC_ACM_DEVICE_COUNT=1

# Logging
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_RTT_MODE_DROP=y

# UART
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_0_NRF_UARTE=y
CONFIG_UART_0_NRF_FLOW_CONTROL=n

 # UART
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y
CONFIG_UART_0_NRF_UARTE=y
CONFIG_UART_0_NRF_FLOW_CONTROL=n
CONFIG_UART_1_NRF_UARTE=y
CONFIG_UART_1_NRF_FLOW_CONTROL=n

#General
CONFIG_REBOOT=y
CONFIG_HEAP_MEM_POOL_SIZE=16384
CONFIG_POLL=y

I just added USB and UART related things from your hci_uart_with_usb_uart_bridge project. Am I right about the reset pin? Am I missing something in configuration that makes my PCA20035 board invisible?

Looking forward to read your feedback, Sigurd.

Sincerely,

Bojan.

[Sigurd]

bojan said:

What I noticed while compiling hci_uart_with_usb_uart_bridge project are two warnings about deprecated macros:

bojan said:

Could that be an issue stopping Thingy:91 to be visible?

Yes. NET_BUF_POOL_DEFINE has been replaced with NET_BUF_POOL_FIXED_DEFINE in the latest release. This was done as part of this PR.

bojan said:

Also, can you tell me what is the purpose of that Reset pin coming from nRF9160 to nRF52840?

It’s used to reset the nRF52840 during startup/reset of the nRF9160. See the comments in the function bt_hci_transport_setup(). When the nRF9160 is reset, the nRF52840 will also reset. It's a kind of synchronization mechanism that ensures that the nRF52840 is in a good known state when nRF9160 setup the HCI transport layer between the nRF9160 and nRF52840 at startup.

bojan said:

I wanted to add usb_uart thread to the bluetooth central_uart example

You want to combine the usb_uart_bridge with the central_uart example ?

I don't understand why you want to do that. If you go for the same architecture as used in the lte_ble_gateway sample, then you want to run the HCI controller on the nRF52840 together with the usb_uart_bridge. (hci_uart_with_usb_uart_bridge). Then you run the bluetooth central_uart sample(Bluetooth Host + application) on the nRF9160.

The Bluetooth architecture then looks like this:

Adding the usb_uart_bridge to the same figure, you get something like this: