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

Problems with compiling and flashing original Thingy firmware

Hi,

I have downloaded the latest Thingy firmware v2.1.0 and setup the IDE as per [here].(devzone.nordicsemi.com/.../)

The code compiles and upon starting debug with SES, the code can be flashed to the board and the IDE shows that the code is running. However, the smartphone is not able to detect/connect to Thingy's firmware and there is also no blue LED blinking. There are no changes to the code. I have also tried on other examples from nRF SDK 14 (eg. hrs) and it is able to work out of the box + able to connect to the phone with debug.

My setup & config:

  1. Firmware: Thingy Firmware v2.1.0
  2. Soft device: s132 v4.0.2 - from the html documentation (and have also tried s132 v5.0.x)
  3. Flash method: nRF52 DK port P20 connected to Thingy (hardware connection has been verify with reference hex and it is working)
  4. Project files: Imported from Keil configuration
  5. nRF SDK: SDK 14
  6. Compiled hex size: 590 kB

I have also tried:

  1. Running the firmware from the provided ses project files in thingy SDK v2.1.0 --> unable to compile due to many missing files
  2. Flash the compiled application hex and s132 v4.0.2 with nRFGo Studio --> no response
  3. Erase all and re-flash the app+SD hex --> no response
  4. Flash with a new bootloader with own public key --> board keeps running in DFU mode
  5. Upload the compiled hex with nRF Connect on an android app --> DFU connection disconnected
  6. Flash softdevice versions s132 v3.0.x and s132 v5.0.x using nRFGo Studio and then the application hex

Others:

  • Flash the thingy_v2.1.0.HW_1.0.hex from Nordic's website --> it works
  • OTA DFU with thingy_dfu_pkg_app_v2.1.0.HW_1.0.zip --> works

Are there any other setup to flash the FW to the board? Is this due to the bootloader FW, SES project settings, soft device version, flash segment placement or any other factors?

If anyone has make it work, greatly appreciate any advice on this. Many thanks in advance!

Updated 23/10/2017: Found out later that this can be solved with:

  • After reading about some old posts, found out that SES setting should not "start from entry point" as it should go to SoftDevice's ResetHandler(). Otherwise, it will cause the application to jump to unknown functions and hence, there's no response from the board. Ref: read "Important Fixes" at here
  • Enabling log will show the recommended SRAM_START address. For s132 v5.0, SRAM_START=0x20004290 works for me.b)
Related