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

[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