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).

[Ø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

[rnouse]

Sorry for confusion, I've tried to explain that everything works fine with the same board under Windows, but doesn't work under Mac/Linux. If the nRF Programmer wasn't able to communicate properly (due to port usage/configuration/driver/OS-level/whatever), then it is a legal error when the Programmer app assumes that the board not in MCUBoot mode (but actually it is). And an attempt to use Programmer sometimes lead to reboot the Thingy into normal mode (leds starts blinking):

$ (echo -en "\x06\tAAsCAAABAAAABaDJ2A==\n"; cat) | picocom --b 115200 -q /dev/ttyACM0
ABADAAAGAAAABb9icmMA/xXW
*** Booting Zephyr OS build v2.1.99-ncs1-1145-g13dc96f83bab  ***
Flash regions Domain Permissions
00 02 0x00000 0x18000 Secure rwxl
03 31 0x18000 0x100000 Non-Secure rwxl

I saw those docs, but it doesn't state which MCU is actually drive the USB. I thought that the main MCU is nRF9160 and nRF52 is a slave device with some internal connection between them. But what you have explained, it's 180º different.

[Øyvind]

rnouse said:

I saw those docs, but it doesn't state which MCU is actually drive the USB. I thought that the main MCU is nRF9160 and nRF52 is a slave device with some internal connection between them. But what you have explained, it's 180º different.

I'm sorry, in what way have I mislead you? I have focused on the nRF9160 at all times, which is the main device on the Thingy:91. The nRF52 provides the USB connection, acts as slave to nRF9160, and therefore must have the Connectivity Bridge programmed in order to function properly.  As the nRF9160 does not provide a USB connection, the nRF52 acts as a bridge between the computer and nRF9160. 

 

I'm trying to get Thingy91 works under either Mac OS or Linux

 This is your initial sentence. This is what I've been trying to assist you with. 

[rnouse]

Øyvind said:

I'm sorry, in what way have I mislead you? I have focused on the nRF9160 at all times, which is the main device on the Thingy:91. The nRF52 provides the USB connection, acts as slave to nRF9160, and therefore must have the Connectivity Bridge programmed in order to function properly.  As the nRF9160 does not provide a USB connection, the nRF52 acts as a bridge between the computer and nRF9160. 

So, the tricky part is: "nRF9169 is the main device. The nRF52 provides (didn't find that in the doc) the USB connection, acts as a slave to nRF9160. [...] the nRF52 acts as a bridge between the computer and nRF9160". This wasn't obvious. I have a Feather device with only nRF9160. It also has UART exposed to USB through TTL converter.

I assume that nRF9160 is a main device and should be bridge to nRF52. However, it controversial. That's why block diagram might be helpful.

From the schematics:

To properly understand this, I've check actual sheets for nRF91 and nRF52. E.g. COEX and MCU_IF has non-sense without comments/datasheet. And this diagram shows only relationship between schematics sheets. The point of interest is how nRF91 and nRF52 relates to each other in terms of shared pins and how the stuff is exposed externally (e.g. USB).

[Øyvind]

rnouse said:

So, the tricky part is: "nRF9169 is the main device. The nRF52 provides (didn't find that in the doc) the USB connection, acts as a slave to nRF9160. [...] the nRF52 acts as a bridge between the computer and nRF9160". This wasn't obvious. I have a Feather device with only nRF9160. It also has UART exposed to USB through TTL converter.

 I'm not sure what you are trying to say, however, this is stated in the Thingy:91 Documentation.

It states under nRF9160
The nRF9160 is the main device of Nordic Thingy:91. It is a compact, highly integrated System in Package (SiP) that makes use of the latest low-power LTE technology. It has advanced processing capabilities and security features. It also has the accessibility and flexibility to be used with a wide range of single-device low-power cellular IoT applications.

And under nRF52840
For Universal Serial Bus (USB), Bluetooth , and Near Field Communication (NFC) passive tag connectivity, Nordic Thingy:91 uses a nRF52840 System on Chip (SoC). It is a powerful, highly flexible, ultra-low power SoC that incorporates a Bluetooth Low Energy radio and a 32-bit Arm Cortex-M4F CPU.

Specifically: 
The Nordic Thingy:91 USB connector is connected to the USB interface of the nRF52840 SoC. This enables PC communication and battery charging.

Currently there are two "official" methods of programming the Thingy:91, stated in the documentation

• Using USB (MCUboot)
• Using an external debug probe

 Based on this, there are two things you can program on the Thingy:91

• Programming applications on Nordic Thingy:91 (on nRF9160 or nRF52840)
• Programming the Nordic Thingy:91 modem

 

rnouse said:

To properly understand this, I've check actual sheets for nRF91 and nRF52. E.g. COEX and MCU_IF has non-sense without comments/datasheet. And this diagram shows only relationship between schematics sheets. The point of interest is how nRF91 and nRF52 relates to each other in terms of shared pins and how the stuff is exposed externally (e.g. USB).

 The COEX pins are described here and specifically in the nRF9160 PS.

Regarding the MCU_IF pins, see this answer from mye colleague Heidi here.