This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mac OS & Linux support

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

Parents
  • Hello ,

    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

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

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

Children
  • Hello, 

    Just to be clear, were you able to update modem FW at one point? Using MCUboot to update modem will also wipe the application area, which means you must program the application again. This would explain why you do not have anything in the output of LTE Link Monitor (if mcuboot is not enabled on device)

    Have you ensured that the "Enable MCUboot" is tagged when running either modem update or application update?

    I'm not familiar with the dfu-util, and can't help with that I'm afraid.

    Can you provide a full screenshot of the programmer app? What more is showing in the device list:

    Kind regards,
    Øyvind

  • Programmer:

    An attempt to write Modem firmware and Application:

    Under Windows:

    I can (re-)program it successfully:

    LTE Link Monitor works well:

    But even under Windows, BLE doesn't work:

    The Config.txt has this line:

    BLE_ENABLED=1

  • Re dfu-util, it was requested by Getting Started Assistant. Usually, DFU used as a method to program ARM Cortex SoCs through serial port instead of JTAG/SWD/whatever:

  • The chip marked as B0 (that is revision 1).

  • I've tried under Linux once again to access ttyACM0 port and replay what Programmer has tried to write to the port (some base64-encoded string). In reply device prints another base64-encoded binary string and just boots normally:

    $ (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
    
    Non-secure callable region 0 placed in flash region 2 with size 32.
    
    SRAM region Domain Permissions
    00 07 0x00000 0x10000 Secure rwxl
    08 31 0x10000 0x40000 Non-Secure rwxl
    
    Peripheral Domain Status
    00 NRF_P0               Non-Secure OK
    01 NRF_CLOCK            Non-Secure OK
    02 NRF_RTC0             Non-Secure OK
    03 NRF_RTC1             Non-Secure OK
    04 NRF_NVMC             Non-Secure OK
    05 NRF_UARTE1           Non-Secure OK
    06 NRF_UARTE2           Secure SKIP
    07 NRF_TWIM2            Non-Secure OK
    08 NRF_SPIM3            Non-Secure OK
    09 NRF_TIMER0           Non-Secure OK
    10 NRF_TIMER1           Non-Secure OK
    11 NRF_TIMER2           Non-Secure OK
    12 NRF_SAADC            Non-Secure OK
    13 NRF_PWM0             Non-Secure OK
    14 NRF_PWM1             Non-Secure OK
    15 NRF_PWM2             Non-Secure OK
    16 NRF_PWM3             Non-Secure OK
    17 NRF_WDT              Non-Secure OK
    18 NRF_IPC              Non-Secure OK
    19 NRF_VMC              Non-Secure OK
    20 NRF_FPU              Non-Secure OK
    21 NRF_EGU1             Non-Secure OK
    22 NRF_EGU2             Non-Secure OK
    23 NRF_DPPIC            Non-Secure OK
    24 NRF_GPIOTE1          Non-Secure OK
    25 NRF_REGULATORS       Non-Secure OK
    
    SPM: NS image at 0x18200
    SPM: NS MSP at 0x200305b0
    SPM: NS reset vector at 0x28805
    SPM: prepare to jump to Non-Secure image.
    *** Booting Zephyr OS build v2.1.99[00:00:00.193,542] <inf> BH1749: BH1749 initialized
    -ncs1-1145-g13dc96f83bab  ***
    [00:00:00.204,254] <inf> asset_tracker: Asset tracker started
    [00:00:00.217,620] <dbg> nrf_cloud_transport.nct_client_id_get: client_id = nrf-352656101502402
    [00:00:00.226,867] <dbg> nrf_cloud_transport.nct_topics_populate: shadow_base_topic: $aws/things/nrf-352656101502402/shadow
    [00:00:00.238,586] <dbg> nrf_cloud_transport.nct_topics_populate: accepted_topic: nrf-352656101502402/shadow/get/accepted
    [00:00:00.250,122] <dbg> nrf_cloud_transport.nct_topics_populate: rejected_topic: $aws/things/nrf-352656101502402/shadow/get/rejected
    [00:00:00.262,756] <dbg> nrf_cloud_transport.nct_topics_populate: update_delta_topic: $aws/things/nrf-352656101502402/shadow/update/delta
    [00:00:00.275,665] <dbg> nrf_cloud_transport.nct_topics_populate: update_topic: $aws/things/nrf-352656101502402/shadow/update
    [00:00:00.287,536] <dbg> nrf_cloud_transport.nct_topics_populate: shadow_get_topic: $aws/things/nrf-352656101502402/shadow/get
    [00:00:00.299,713] <inf> asset_tracker: Connecting to LTE network. 
    [00:00:00.306,488] <inf> asset_tracker: This may take several minutes.
    [00:00:00.321,929] <dbg> lte_lc.w_lte_lc_connect: Network mode: AT%XSYSTEMMODE=1,0,1,0
    +CEREG: 2,"03F2","0116F105",7,0,0,"11100000","11100000"
    [00:00:01.833,129] <dbg> lte_lc.parse_nw_reg_status: Network registration status: 2
    +CEREG: 5,"03F2","0116F105",7,,,"11100000","11100000"
    [00:00:03.149,291] <dbg> lte_lc.parse_nw_reg_status: Network registration status: 5
    [00:00:03.157,592] <inf> asset_tracker: Connected to LTE network
    [00:00:03.351,593] <dbg> nrf_cloud_transport.nct_connect: IPv4 Address 0xb2a4de03
    [00:00:03.359,558] <dbg> nrf_cloud_transport.nct_mqtt_connect: mqtt_connect requesting persistent session
    AT+CIMI
    204080813556262
    OK
    [00:00:08.619,506] <dbg> aws_fota.aws_fota_mqtt_evt_handler: Previous session valid; skipping FOTA subscriptions
    [00:00:08.630,249] <inf> aws_fota: Created notify_next_topic $aws/things/nrf-352656101502402/jobs/notify-next
    [00:00:08.640,716] <inf> aws_fota: Created get_topic $aws/things/nrf-352656101502402/jobs/$next/get/#
    [00:00:08.650,421] <inf> aws_fota: previously subscribed to notify-next topic
    [00:00:08.658,081] <inf> aws_jobs: Publish topic: $aws/things/nrf-352656101502402/jobs/$next/get
    [00:00:08.667,358] <inf> aws_jobs: Publish payload {"clientToken": ""}
    [00:00:08.675,842] <dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_CONNACK
    [00:00:08.683,990] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 2
    [00:00:08.691,680] <dbg> nrf_cloud.event_handler: NRF_CLOUD_EVT_TRANSPORT_CONNECTED
    [00:00:08.699,798] <inf> asset_tracker: CLOUD_EVT_CONNECTED
    [00:00:08.705,841] <inf> asset_tracker: Persistent Sessions = 1
    [00:00:08.712,249] <dbg> nrf_cloud_fsm.connection_handler: Previous session valid; skipping nct_cc_connect()
    [00:00:08.722,534] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 4
    [00:00:08.730,224] <dbg> nrf_cloud_transport.nct_cc_send: mqtt_publish: id = 5678 opcode = 0 len = 0
    [00:00:08.740,692] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 5
    [00:00:09.108,001] <dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 5678 result = 0
    [00:00:09.118,103] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 5
    [00:00:09.126,007] <dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 22097 result = 0
    [00:00:09.175,598] <dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656101502402/jobs/$next/get/accepted
    [00:00:09.187,164] <inf> aws_fota: Checking for an available job
    [00:00:09.193,695] <dbg> aws_fota.get_job_execution: Job doc: {"clientToken":"","timestamp":1602342825}
    [00:00:09.203,735] <dbg> aws_fota.get_job_execution: Got only one field
    [00:00:09.210,815] <inf> aws_fota: No queued jobs for this device
    [00:00:09.288,482] <dbg> aws_fota.on_publish_evt: Received topic: nrf-352656101502402/shadow/get/accepted
    [00:00:09.298,522] <dbg> aws_fota.on_publish_evt: received an unhandled MQTT publish event on topic: nrf-352656101502402/shadow/get/accepted
    [00:00:09.311,614] <dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 16372 len = 317
    [00:00:09.322,448] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 5
    [00:00:09.330,139] <dbg> nrf_cloud.event_handler: NRF_CLOUD_EVT_RX_DATA
    [00:00:09.337,219] <inf> asset_tracker: CLOUD_EVT_DATA_RECEIVED
    [00:00:09.344,085] <inf> cloud_codec: [cloud_search_config:898] Found cfg item GPS, enable
    
    [00:00:09.354,675] <dbg> nrf_cloud_transport.nct_dc_endpoint_set: nct_dc_endpoint_set
    [00:00:09.363,098] <dbg> nrf_cloud_transport.nct_dc_endpoint_get: nct_dc_endpoint_get
    [00:00:09.372,344] <dbg> nrf_cloud_transport.nct_cc_send: mqtt_publish: id = 7890 opcode = 1 len = 329
    [00:00:09.383,941] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 7
    [00:00:09.391,632] <dbg> nrf_cloud.event_handler: NRF_CLOUD_EVT_USER_ASSOCIATED
    [00:00:09.399,414] <inf> asset_tracker: CLOUD_EVT_PAIR_DONE
    [00:00:09.853,759] <dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 7890 result = 0
    [00:00:09.863,830] <dbg> nrf_cloud_fsm.cc_tx_ack_handler: Previous session valid; skipping nct_dc_connect()
    [00:00:09.874,053] <dbg> nrf_cloud.nfsm_set_current_state_and_notify: state: 9
    [00:00:09.881,744] <dbg> nrf_cloud.event_handler: NRF_CLOUD_EVT_READY
    [00:00:09.888,641] <inf> asset_tracker: CLOUD_EVT_READY
    [00:00:09.911,651] <dbg> nrf9160_gps.init: GPS socket created, fd: 1232491587
    [00:00:09.919,494] <inf> gps_control: GPS initialized
    [00:00:09.961,242] <dbg> nrf_cloud_transport.nct_cc_send: mqtt_publish: id = 1 opcode = 1 len = 628
    [00:00:10.399,780] <dbg> nrf_cloud_transport.nct_mqtt_evt_handler: MQTT_EVT_PUBACK: id = 1 result = 0
    AT+CFUN?
    +CFUN: 1
    OK
    AT+CIMI
    204080813556262
    OK

    And LTE Linux Monitor works under Linux, but the programmer -- not.
    When I've tried to do so under Mac OS, the device boots to the normal mode as well, but didn't output anything to the terminal.
    Only once I got an output like:
    $ (echo -en "\x06\tAAsCAAABAAAABaDJ2A==\n"; cat) | picocom --b 115200 -q /dev/tty.usbmodem14101
    [00:00:00.772,308] <err> at_host: Error while processing AT command: -8
    ERROR
    without changing anything for the port settings. All time the device keeps the silence.

    Some diag info:
    $ ioreg -p IOUSB
    +-o Root <class IORegistryEntry, id 0x100000100, retain 17>
    +-o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x10000035e, registered, matched, active, busy 0 (11 ms), retain 16>
    +-o Thingy:91 UART@14100000 <class AppleUSBDevice, id 0x1000524e9, registered, matched, active, busy 0 (33 ms), retain 22>
    
    $ sudo kextstat | grep  usb
    196 2 0xffffff7f83d79000 0x7000 0x7000 com.apple.driver.usb.cdc (5.0.0) 7D401B3D-415A-3D8E-92AA-1172B49CF325 <195 109 27 6 5 3 1>
    201 1 0xffffff7f83dfd000 0x6000 0x6000 com.apple.driver.usb.serial (6.0.0) 2CD7A00D-7FE0-32B6-8356-0282E8A56108 <102 27 6 5 3 1>
    202 0 0xffffff7f83e03000 0x8000 0x8000 com.apple.driver.usb.cdc.acm (5.0.0) 3AE15D79-8672-372E-AB15-D1C7B751B09C <201 196 195 109 102 27 6 5 3 1>
    203 0 0xffffff7f83e0b000 0xc000 0xc000 com.apple.driver.usb.cdc.ecm (5.0.0) E7034D01-BB4C-3148-99BD-3904CE5DD589 <196 109 27 26 18 6 5 3 1>
Related