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.

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
  • Thanks for your reply. As I could not find any reference to files in img_app_bl folder, so I was trying with files in img_fota_dfu_hex folder. After I used files from img_app_bl, I can program it now. Thank you so much for the useful information. I just want to buil my own custom application and want to use Thingy91 as a testing platform. So, wants to ask you if you can answer my following questions.

    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.

    1. Can you please provide some resource which can be helpful in doing these three things you mentioned earlier?

        Because I tried with a simple hello_world application in ncs\v1.4.1\zephyr\samples folder using non-secure option. This time I used merged.hex file in the build folder (created while compiling the code). But Thingy91 is not responding to this simple application. This application is having one line code using printk function to print string on serial port.

    2. What is the procedure to build custom application for Thingy91?

    Thanks a lot!

    -Shiv

  • Hi, and sorry for the late reply.

     

    Shivek said:
    2. What is the procedure to build custom application for Thingy91?

     As long as you don't need to support the bootloader on the Thingy:91, same as building any other application.

    Build your application for the thingy91_nrf9160ns board.

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/nrf/ug_thingy91.html

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/nrf/ug_nrf9160.html

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/nrf/ug_app_dev.html

     

    Shivek said:
    1. Can you please provide some resource which can be helpful in doing these three things you mentioned earlier?

     When building multi-image projects (i.e. projects with application, SPM and/or bootloader), the flash is partitioned dynamically at build time by the Partition Manager script.

    However, when building new versions of the project (or other projects), the Partition Manager might generate a new flash partition than the one used by the bootloader already on the device. This will cause problems, especially if the application has to mark itself as Ok for the bootloader to not revert the update. The way around this problem is to use a static configuration of the flash. This is usually done by building the project normally (without a static partition scheme) for the first version, then extract the partitioning scheme from the build folder, and use that as a static configuration in future builds.

    To use the same flash partitioning as the Thingy:91 bootloader, you can copy the pm_static.yml file from nrf/application/asset_tracker/configuration/thingy91_nrf9160ns to your project folder (it should be next to the CMakeLists.txt file), and set CONFIG_BOOTLOADER_MCUBOOT=y in your prj.conf.

    However, depending on the NCS version, you might also have to add the following lines to the CMakeLists.txt, right below the line specifying the CMake version:

    list(APPEND mcuboot_OVERLAY_CONFIG
      "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot_overlay-rsa.conf"
      )

    and add this file to your project directory:

    mcuboot_overlay-rsa.conf

Reply
  • Hi, and sorry for the late reply.

     

    Shivek said:
    2. What is the procedure to build custom application for Thingy91?

     As long as you don't need to support the bootloader on the Thingy:91, same as building any other application.

    Build your application for the thingy91_nrf9160ns board.

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/nrf/ug_thingy91.html

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/nrf/ug_nrf9160.html

    https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.4.0/nrf/ug_app_dev.html

     

    Shivek said:
    1. Can you please provide some resource which can be helpful in doing these three things you mentioned earlier?

     When building multi-image projects (i.e. projects with application, SPM and/or bootloader), the flash is partitioned dynamically at build time by the Partition Manager script.

    However, when building new versions of the project (or other projects), the Partition Manager might generate a new flash partition than the one used by the bootloader already on the device. This will cause problems, especially if the application has to mark itself as Ok for the bootloader to not revert the update. The way around this problem is to use a static configuration of the flash. This is usually done by building the project normally (without a static partition scheme) for the first version, then extract the partitioning scheme from the build folder, and use that as a static configuration in future builds.

    To use the same flash partitioning as the Thingy:91 bootloader, you can copy the pm_static.yml file from nrf/application/asset_tracker/configuration/thingy91_nrf9160ns to your project folder (it should be next to the CMakeLists.txt file), and set CONFIG_BOOTLOADER_MCUBOOT=y in your prj.conf.

    However, depending on the NCS version, you might also have to add the following lines to the CMakeLists.txt, right below the line specifying the CMake version:

    list(APPEND mcuboot_OVERLAY_CONFIG
      "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot_overlay-rsa.conf"
      )

    and add this file to your project directory:

    mcuboot_overlay-rsa.conf

Children
No Data
Related