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]

So, under the windows (I use cygwin) I did the same, just printf to /dev/ttyS7 (COM8). That lead the Thingy to restart.

What shows the strace for nRF Programmer on attempt to write the image regardless which IC has been in MCUboot mode:

# strace -f -etrace=writev,readv -p ...
4302 writev(76, [{iov_base="\6\tAAsCAAABAAAABaDJ2A==\n", iov_len=23}], 1 <unfinished ...>
4302 <... writev resumed>) = 23

# At this point Thingy reboots
4302 readv(76, [{iov_base=0x18e0572ae400, iov_len=1024}], 1) = -1 EAGAIN (Resource temporarily unavailable)

# Same with "-x" flag:
4303 writev(86, [{iov_base="\x06\x09\x41\x41\x73\x43\x41\x41\x41\x42\x41\x41\x41\x41\x42\x61\x44\x4a\x32\x41\x3d\x3d\x0a", iov_len=23}], 1) = 23

[rnouse]

I finally got my Segger emulator. I did little debug of the nRF52. 

Right after pressing "Write" button in Programmer. The "line" string has the correct value as it was explored above using "strace" under Linux:

Buffer looks good:

00 0b 02 00 00 01 00 00  00 05 a0 c9 d8

but it has nh_group set to MGMT_GROUP_ID_DEFAULT and nh_id set to NMGR_ID_RESET that lead to board reset that I observed.

Here is what actually happens on Windows:

The first sent line is: "\006\tAAsCAAABAAEABaC/bA==\n" that is different from MacOS / Linux:

00 0b 02 00 00 01 00 01  00 05 a0 bf 6c

The difference is nh_group that is MGMT_GROUP_ID_IMAGE with the same nh_id equal to "5" that is unsupported and just falls into empty response.

So, under Windows we have a bit different commands flow:

And the next read command is actually an image upload:

when Programmer under Windows reports it's sending the data.

[rnouse]

Seems like nRF Programmer code falls into this call:

https://nordicsemiconductor.github.io/pc-nrfjprog-js/module-pc-nrfjprog-js.html#.programMcuBootDFU

That invokes proprietary API from libhighlevelnrfjprog.dylib. I can not dive deeper without bringing up IDA. That's a bit an effort :) 

[Øyvind]

rnouse, thank you for providing this information to us. This is much appreciated. I will forward this to our team. I have been out of office the last week, and not been able to respond to your messages, and for that I apologize. 

[rnouse]

Any additional info needed?

[Øyvind]

No thank you. I have registered an internal ticket, and will get back to you when I receive an answer. However, our SW team is currently working at high capacity, that means I do not have an estimate of when we'll have an answer I'm afraid.