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.