Mac OS & Linux support

[rnouse]

I'm trying to get Thingy91 works under either Mac OS or Linux. Neither of Programmer nor LTE Link Monitor doesn't work. Programmer complains about that device is not in MCU mode, LTE Link Monitor do not get any response from the port. I've tried to hold SW3 before switching Thingy on. I saw MCUBOOT USB device in the list, but dfu-util doesn't report any compatible devices and running with several "-v" arguments doesn't make sense when getting output from libusb. Same for Linux. I've tried to power cycle and hold SW3 many times.

The only way when the Programmer and Monitor works is under Windows. With the first attempt I was able to update firmware & use LTE Monitor. Windows was physically run on the same machine as Linux (dual boot). I've tried to "strace" the process that do DFU-related things under Linux, but there is no glue why it doesn't work: the code tries to write firmware as base64 encoded string and got nothing back. Under Mac OS I use various kind of usb-serial devices with a speed up to 3M without any issues.

And how to get BLE work? I've updated Config.txt file on the virtual flash device to enable BLE, but after power cycling it still not available under BLE tool: it reports operation timeout when attempting to communicate to BLE device even under Windows.

PS. I use the most recent nRF Connect v3.5.0. Tried with Mac OS 10.15.7 and Ubuntu 20.04 (no permission issues while accessing /dev/ttyACMx devices).

[Øyvind]

Hello rnouse,

I'm sorry to hear about these issues. We need to handle one topic at a time here. 

I'm trying to get Thingy91 works under either Mac OS or Linux. Neither of Programmer nor LTE Link Monitor doesn't work. Programmer complains about that device is not in MCU mode, LTE Link Monitor do not get any response from the port. I've tried to hold SW3 before switching Thingy on. I saw MCUBOOT USB device in the list, but dfu-util doesn't report any compatible devices and running with several "-v" arguments doesn't make sense when getting output from libusb. Same for Linux. I've tried to power cycle and hold SW3 many times.

What are you trying to do? What are the error messages you get? Have you updated the modem FW or application FW? Can you please elaborate what "running with several "-v" arguments" means when using the Programmer app? Please note that in order to generate an DFU image for the Thingy:91, one must use NCS. See this information on "Developing and programming from the source code". 

Are you using a new Thingy:91?

Thank you. 

Kind regards,
Øyvind

[rnouse]

I've tried to update Modem firmware as well as Application firmware from the precompiled archives as mentioned over here (just follow up the steps):

https://www.nordicsemi.com/Software-and-tools/Prototyping-platforms/Nordic-Thingy-91/GetStarted#infotabs

The programmer complains:

The LTE Link Monitor even after power cycle can not read anything from the port (neither in Mac nor Linux):

But it works perfectly under Windows. Even after FW upgrade, the device still not reachable from Mac OS or Linux.

On Mac OS the dfu-util shows nothing useful:

$ sudo dfu-util -l  -U aaa.bin -vvvv
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

[timestamp] [threadID] facility level [function call] <message>
--------------------------------------------------------------------------------
[ 0.006530] [00000307] libusb: debug [libusb_get_device_list]
[ 0.006597] [00000307] libusb: debug [libusb_get_device_descriptor]
[ 0.006605] [00000307] libusb: debug [libusb_get_config_descriptor] index 0
[ 0.006618] [00000307] libusb: debug [parse_configuration] skipping descriptor 0xb
[ 0.006635] [00000307] libusb: debug [parse_endpoint] skipping descriptor b
[ 0.006646] [00000307] libusb: debug [libusb_get_device_descriptor]
[ 0.006649] [00000307] libusb: debug [libusb_get_config_descriptor] index 0
[ 0.006654] [00000307] libusb: debug [libusb_get_device_descriptor]
[ 0.006657] [00000307] libusb: debug [libusb_get_config_descriptor] index 0
[ 0.006661] [00000307] libusb: debug [libusb_get_device_descriptor]
[ 0.006664] [00000307] libusb: debug [libusb_get_config_descriptor] index 0
dfu-util: No DFU capable USB device available

I've tried different combos of "-d" values to explicitly set the vendor:product ids as well as using "-D" param instead of reading "-U" to actually write an image in hex format.

The Thingy91 is the one I recently ordered. On the box it is labeled as: 1.4.0 / 2020.24 (same on the PCB's label).

[rnouse]

I've updated nRF52840 with the image above, the reflash Modem and App from the latest version 09.23 (that was rebuild with latest SDK). Also have updated nRF Connect to 3.6.0. 

Under Linux I can use LTE Link Monitor, but the Programmer still doesn't work. BLE app doesn't work as well. By the way, the app has tried to open the same device for BLE. Even if I swapped files (ttyACM0 <> ttyACM1) it doesn't work. Just curious, why there are two serial ports, but the LTE Link app communicates at 115200, but BLE app has tried to communicate at 1M.

On Mac OS everything is the same. After reboot from Linux, I was able to open port in terminal program to enter AT commands, I've tried to enter MCUBoot and re-flash -- it doesn't work. After the reset I got the same state of serial port: even terminal program has stopped to work.

Summarizing: BLE still doesn't work, Programmer works under Windows only, LTE Link Monitor works under Linux. On Mac OS none of the above works properly :(

[Øyvind]

Hello, 
 

rnouse said:

I've updated nRF52840 with the image above, the reflash Modem and App from the latest version 09.23 (that was rebuild with latest SDK). Also have updated nRF Connect to 3.6.0. 

Did you update the modem and app before updating to v3.6.0 of nRF Connect for Desktop?

 

rnouse said:

BLE app doesn't work as well. By the way, the app has tried to open the same device for BLE. Even if I swapped files (ttyACM0 <> ttyACM1) it doesn't work. Just curious, why there are two serial ports, but the LTE Link app communicates at 115200, but BLE app has tried to communicate at 1M.

 The BLE app does function with the Thingy:91 running Connectivity_bridge.  

 

rnouse said:

On Mac OS everything is the same. After reboot from Linux, I was able to open port in terminal program to enter AT commands, I've tried to enter MCUBoot and re-flash -- it doesn't work. After the reset I got the same state of serial port: even terminal program has stopped to work.

 What is failing? What is the error? Are you still getting "Please make sure device is in MCUboot mode"? Or does it fail during flashing?

-Øyvind

[rnouse]

I did reflash rF52840 several times. The last one was using the latest nRF Connect Desktop and updated Programmer (v1.4.6).

I've also tried to flash Connectivity Bridge app, but it didn't help: 

The error in BLE App still the same.

The error in Programmer under either Linux or Mac OS complains about MCUboot mode.

I'm confused about UART_0 and UART_1. What the purpose of second port? And why some apps opens the same port at different speeds? E.g. under Linux LTE Link opens ttyACM0 as well as BLE App, but with different speeds. Documentation doesn't explain that.

I thought that one port belongs to nRF9160 and another to nrf52840. There is only one serial port being exposed on nRF9160 Feather.

The option BLE_ENABLED in Config.txt has only sense for Connectivity Bridge app? 

[rnouse]

However, I can use mcumgr to update firmware under Mac OS, but seems pretty slow (e.g. 9600):

$ ~/go/bin/mcumgr --conntype=serial --connstring=/dev/tty.usbmodem14101 image upload thingy91_fw_2020-04-29_bc7ade8b/images_dfu_bin/thingy91_nrf52_connectivity_bridge_dfu_2020-04-29_bc7ade8b.bin

310.19 KiB / 310.19 KiB [======================================================================] 100.00% 998 B/s 5m18s
Done

[Øyvind]

The connectivity bridge will help with getting the MCUboot up and running, so that you are able to update and program the nRF9160 on the Thingy:91. Connectivity Bridge does not allow the usage of the BLE app. Please open a new ticket for this issue.

As explained earlier, let's focus on the MCUboot and the programmer app issue on your side. What it is the current status of MCUboot? Are you able to put the nRF9160 into MCUboot mode and update both modem firmware and the application firmware? 

[rnouse]

Øyvind said:

The connectivity bridge will help with getting the MCUboot up and running, so that you are able to update and program the nRF9160 on the Thingy:91.

You mean use connectivity bridge to get BLE module to get into MCUboot?

I got running MCUboot mode either for nRF9160 (SW3) and BLE (SW4). The issue is not with MCUboot on the Thingy:91, but how it works under Linux / Mac OS. At least, it works smoothly under Windows. Under MacOS I was able to enter MCUboot as well and use command line "mcumgr", but it very slow. The thing is that Programmer app doesn't work nether on Linux nor Mac OS.

The error with Programmer still the same as mentioned above. The Programmer complains that the board is not in MCUboot mode.

[Øyvind]

As described in the documentation:
The connectivity bridge is what allows the device enter MCUboot. The nRF52840 running the Connectivity Bridge acts as a USB composite device, exposing two UART interfaces to a USB host as two CDC ACM devices. The application also provides a Bluetooth LE UART Service (Nordic UART Service (NUS)), which can be enabled by the option CONFIG_BRIDGE_BLE_ENABLE. This service can be used for a wireless connection to one of the UART interfaces does support .

The UART ports opened are used in the following way:

UART_0: AT-commands and logging (what you see in LTE Link Monitor), and if you enable BLE as described in documentation, it will also transfer data here.
UART_1: Is for modem traces, and is by default disabled.

For the Thingy:91, I'm currently focusing on getting MCUboot up and running for you in MacOS/Linux to update the nRF9160. After programming the nRF52840 with the connectivity bridge, are you able to start nRF9160 in MCUboot? If so, you should be able to update the modem firwmare and application firmware on the nRF9160 using the programmer app on Mac OS and Linux. 

[rnouse]

Øyvind said:

After programming the nRF52840 with the connectivity bridge, are you able to start nRF9160 in MCUboot?

Sorry for confusing, perhaps, we are not on the same page. I was able to flash App & modem firmware for nRF9160 only under Windows using nRF Programmer. Under Mac OS I was able to use only mcumgr cli tool to flash App for nRF9160. I will check mcumgr under Linux as well. This doesn't seem to be an MCUBoot issue on the Thingy side. Otherwise, the flashing wouldn't work at all.

[rnouse]

Also it might be great to have a block diagram in the doc describing how UARTs are connected within nRF9160 and nRF52840 and exposed as USB Composite device.

Because till the date, I tho that nRF9160 is exposing the UART from both devices.

Even when firmware readme says: Connectivity bridge for the nrf52, I've thought that it an app for nRF9160 because all other firmware files belongs to it.

PS. The attached file 5824.app_signed.hex I've flashed into nRF52 :) that was clear

[Øyvind]

rnouse said:

Sorry for confusing, perhaps, we are not on the same page. I was able to flash App & modem firmware for nRF9160 only under Windows using nRF Programmer. Under Mac OS I was able to use only mcumgr cli tool to flash App for nRF9160. I will check mcumgr under Linux as well. This doesn't seem to be an MCUBoot issue on the Thingy side. Otherwise, the flashing wouldn't work at all.

i'm sorry, I thought that getting MCUboot was the issue here, as you complained that your programmer app reports:   

 

rnouse said:

Also it might be great to have a block diagram in the doc describing how UARTs are connected within nRF9160 and nRF52840 and exposed as USB Composite device.

 The documentation does state this, both under
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_thingy91.html#working-with-thingy-91

and 

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/connectivity_bridge/README.html