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]

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.

[rnouse]

I'm trying to use nrfutil to flash the device under Mac OS or even under Windows (unsure about a proper value for SoftDevice req value):

$ nrfutil pkg generate --sd-req 0xaf \
  --application-version 1 --hw-version 52 \
  --application bnrf/zephyr/zephyr.hex \
  --key-file /.../nordic/sdk/ncs/zephyr/../bootloader/mcuboot/root-ec-p256.pem \
  zephyr.zip

The nrfutil fails identically under Windows / Mac OS:

C:\...\> nrfutil dfu usb-serial -p COM8 --package zephyr.zip -b 115200

2020-11-01 15:13:43,604 No trigger interface found for device with serial number: 33486F522A9958F9, Product ID: 0x520F and Vendor ID: 0x1915

Traceback (most recent call last):
File "C:\Program Files\Python37\Scripts\nrfutil-script.py", line 11, in <module>
load_entry_point('nrfutil==6.1.0', 'console_scripts', 'nrfutil')()
File "c:\program files\python37\lib\site-packages\click\core.py", line 829, in __call__
return self.main(*args, **kwargs)
File "c:\program files\python37\lib\site-packages\click\core.py", line 782, in main
rv = self.invoke(ctx)
File "c:\program files\python37\lib\site-packages\click\core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:\program files\python37\lib\site-packages\click\core.py", line 1259, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "c:\program files\python37\lib\site-packages\click\core.py", line 1066, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "c:\program files\python37\lib\site-packages\click\core.py", line 610, in invoke
return callback(*args, **kwargs)
File "c:\program files\python37\lib\site-packages\nordicsemi\__main__.py", line 1015, in usb_serial
timeout)
File "c:\program files\python37\lib\site-packages\nordicsemi\__main__.py", line 970, in do_serial
dfu.dfu_send_images()
File "c:\program files\python37\lib\site-packages\nordicsemi\dfu\dfu.py", line 127, in dfu_send_images
self._dfu_send_image(self.manifest.application)
File "c:\program files\python37\lib\site-packages\nordicsemi\dfu\dfu.py", line 88, in _dfu_send_image
self.dfu_transport.open()
File "c:\program files\python37\lib\site-packages\nordicsemi\dfu\dfu_transport_serial.py", line 217, in open
self.__get_mtu()
File "c:\program files\python37\lib\site-packages\nordicsemi\dfu\dfu_transport_serial.py", line 366, in __get_mtu
self.mtu = struct.unpack('<H', bytearray(response))[0]
TypeError: 'NoneType' object is not iterable

[rnouse]

Hm, seems like that way I'm missing mcuboot app. It's a part of merged.hex.

However, generated dfu_application.zip file is not suitable to use by nrfutil.

[Øyvind]

I'm sorry, but please read my last comment, which explains how to program the Thingy:91. 

nrfutil dfu does not work with the Thingy:91, only for nRF5 SDK devices. The Thingy:91 uses nRF Connect SDK which is more advanced.

[rnouse]

Yep. I just tried different ways.

The only way that works is only using Windows workstation. Same workstation with Linux or Mac laptop doesn't work with the same MCUboot error. Even more, after an attempt to use Programmer under Mac/Linux, I have to power cycle Thingy to get it flashed under Windows. Looks like some communication happens, but the device fails.

Btw, when I've check what actually Programmer tries to write to the port under the Linux (using strace) and then reproduce it with terminal emulator, the board reboots. Could it be that MCUboot silently crashed? Does it have some verbose option to be enabled? I was able to rebuild the connectivity bridge app and reflash it and it works (again, under Windows).

$ (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
...

Seems like the MCUboot answers something back (base64-encoded string):

ABADAAAGAAAABb9icmMA/xXW

...and reset.