• State Verified Answer
  • Replies 5 replies
  • Subscribers 88 subscribers
  • Views 1288 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 262597
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thingy:91 is unresponsive after programming sample program.

Shivek

Hi,

I just got Thingy:91, and I was trying to see the response for a simple hello_world (found in zephyr\samples) application from Thingy:91. 

Thingy:91 got programmed correctly but it was not showing any response on serial monitor (using Tera term). So, I decided to give it a try to nrf9160 dk with the same code but with different configuration in Segger embedded studio Nordic version.

So, I was programming samples to the Thingy:91 and suddenly it stopped working.

I am using nrf Connect for Windows10 and to program I have tried usb programmer using USB option while enabling MCUboot option, and the external debugger option using nrf9160 dk debugger probe.

Then I decided to give it a whole new firmware update, so I started with nrf52840. While programming it seems to be normal like it was showing device ID properly and I programmed it using USB method but after that I am not able to see the Segger ID of Thingy91 (which is something like nrf9160_20035) in the select device drop down menu, it is showing some other COM port as shown in the picture. 

Furthermore, after updating nrf52840 firmware with thingy91_nrf52_usb_uart_bridge_2020-10-30_5522ca2b.hex file the Link monitor application app is not able to detect the device even though the device is connected and shown in programmer app (as shown in the above picture). 

I have tried updating modem firmware, nrf9160 firmware, but every time I am getting error as shown in the following picture

I am getting this error even I am pressing the SW4 while turning ON the Thingy91 to switch into serial recovery mode.

I would appreciate if anyone can help me.

Parents
  • 0

    Hi,

    Most samples in NCS will not work out-of-the-box on the Thingy:91 unless they are programmed with an external programmer (such as the nRF91DK). The reason for this is that most samples does not use a bootloader, and can therefore not be programmed over DFU. In addition, when modifying a sample to support DFU on the Thingy:91, care must be taken to ensure that the sample uses the same flash layout and signing algorithm and key as the bootloader already on the Thingy:91.

    As you already have an nRF91DK, I recommend that you use that to program the Thingy:91, as you then don't have to worry about compatibility with the existing bootloader.

    Of course, if you program an application without bootloader, you will not be able to do a DFU update of the Thingy:91 without re-programming the bootloader (e.g. from one of the pre-compiled applications for the Thingy:91).

    When doing a DFU update of the nRF52840, you should be using SW4 (the small white button). I also recommend that you use the connectivity_bridge, and not the usb_uart_bridge, as the connectivity_bridge is newer, and has more features (including support for modem traces from the nRF9160).

    When doing a DFU update of the nRF9160, you should be using SW3, the big button in the center of the PCB.

    Best regards,

    Didrik

Reply
  • 0

    Hi,

    Most samples in NCS will not work out-of-the-box on the Thingy:91 unless they are programmed with an external programmer (such as the nRF91DK). The reason for this is that most samples does not use a bootloader, and can therefore not be programmed over DFU. In addition, when modifying a sample to support DFU on the Thingy:91, care must be taken to ensure that the sample uses the same flash layout and signing algorithm and key as the bootloader already on the Thingy:91.

    As you already have an nRF91DK, I recommend that you use that to program the Thingy:91, as you then don't have to worry about compatibility with the existing bootloader.

    Of course, if you program an application without bootloader, you will not be able to do a DFU update of the Thingy:91 without re-programming the bootloader (e.g. from one of the pre-compiled applications for the Thingy:91).

    When doing a DFU update of the nRF52840, you should be using SW4 (the small white button). I also recommend that you use the connectivity_bridge, and not the usb_uart_bridge, as the connectivity_bridge is newer, and has more features (including support for modem traces from the nRF9160).

    When doing a DFU update of the nRF9160, you should be using SW3, the big button in the center of the PCB.

    Best regards,

    Didrik

Children
  • 0 in reply to Didrik Rokhaug

    Hi Didrik,

    Thanks for your reply. I didn't know that with samples we need to configure key and signing algorithm. So, does that mean I probably have corrupted the bootloader? Because I tried programming Thingy91 using nrf9160 DK with app_signed.hex and zephyr.hex files (generated by compiling nrf\applications\asset_tracker application using nRF Connect SDK 1.4.1). But still Thingy91 is not responding after resetting, turning OFF and ON.

    Is there any way to know whether bootloader is fine or not?

    One thing which I found is unusual while programming Thingy91 (through nRF9160 DK) is that the hex file(thingy91_ltem_2020-10-30_5522ca2b.hex provided by Nordic semi.) shown in File memory layout container (right in the picture) have only green portion while earlier it was showing orange portion too.  

    Secondly, after programming this hex file onto Thingy91, when I am reading it back through nRF9160DK its showing in chunks as shown in the left container in above picture.

    Please share your views on this.

    -Shiv

  • 0 in reply to Shivek
    Shivek said:
    I tried programming Thingy91 using nrf9160 DK with app_signed.hex and zephyr.hex files

     When using the modem, the application must be built as non-secure. You can do this by using the thingy91_nrf9160ns (notice the "ns" at the end, the same goes for the DK). When you build your application as non-secure, you will also automatically build the secure Partition Manager sample. The SPM will run before the application, and is what configures the MCU to run in non-secure mode. In addition, if the bootloader is enabled, that will also be built.

    This gives you two or three images that must be flashed to the device: The application, the SPM and the bootloader. To make it easier, all the images will be merged into one hex file called "merged.hex".

    So, instead of flashing zephyr.hex, you should instead flash merged.hex.

    app_signed.hex is the image to use if you are using DFU. It will have SPM and the application, but not the bootloader.

    Shivek said:
    thingy91_ltem_2020-10-30_5522ca2b.hex

     From what folder did you take the image?

    img_app_bl has the bootloader included (merged.hex), and is what you should use when using an external programmer.

    img_fota_dfu_hex and img_fota_dfu_bin does not have the bootloader (app_signed.hex and the equivalent app_update.bin), but are instead meant to be used during DFU.

Related