Whisper Ware (nRf9160)

[John]

Without doubt there is a new variation of software emerging:

We are all familiar with Firmware and Software, however I really feel the need to coin the term "Whisper Ware" when it comes to the nRF9160 which I must add we are absolutely committed to making work.

I have personally spent the last 12 hours, uninstalling, changing branches, reinstalling, and trying my best to follow every "whisper" in this forum to make any of the sample applications work.

Even more frustrating is that for a brief time they did seem to function.

Now whatever I do, AT commands time out as follows:

Error: 'AT+CFUN? ' timed out

If someone would be kind enough to give detailed instruction on how I may be able to start "from scratch" and therefore remove any legacy that may exist, I would be very grateful.

I'm using Windows 10 and clearly very very frustrated.

On the ever positive side, I'm thrilled to bits that the implementation currently is such a mess, as most will or already have simply given up as they will not have the sincere patience that I have.

[Martin Lesund]

Hi John, 

I tested your application "0535.jan_merged.hex".

SPM: NS reset vector at 0xfda1
SPM: prepare to jump to Non-Secure image.
***** Booting Zephyr OS v1.14.99-ncs1-1066-gf210011b9609 *****
Application started
LTE LC config ...
NRF_CLOUD_EVT_TRANSPORT_CONNECTED
NRF_CLOUD_EVT_USER_ASSOCIATION_REQUEST
Please enter the user association pattern using the buttons and switches
Button 2
Button 1
Switch 2
Switch 1
Switch 2
Switch 1
NRF_CLOUD_EVT_USER_ASSOCIATED
NRF_CLOUD_EVT_TRANSPORT_DISCONNECTED
NRF_CLOUD_EVT_TRANSPORT_CONNECTED
NRF_CLOUD_EVT_USER_ASSOCIATED
NRF_CLOUD_EVT_READY
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
NRF_CLOUD_EVT_SENSOR_ATTACHED
GPS device found

Notice the ***** Booting Zephyr OS v1.14.99-ncs1-1066-gf210011b9609 *****

Is different than what you are getting as output.

---

Please do the following;

- Erase what's on the chip: nrfjprog -e

- Confirm that you flash that file the following way:

nrfjprog --program 0535.jan_merged.hex -f nrf91 --sectorerase -r  --verify

Then you should get the same output.

(it is possible that there was "garbage data" from before interfering the application)

Best Regards,
Martin L.

[John]

Hi Martin, I did what you said and yesterday I was getting a different result, whereby I was seeing a continuous reboot complaining about a 111 error. Which in thinking about it may be entirely reasonable because looking at your log you have paired with nrfcloud.

I'm guessing that my connection and CWALLACH's connection is "being refused" because a particular IMEI "yours" already has paired with nrfcloud.

However this morning after

After nrfjprog -e

nrfjprog --program 0535.jan_merged.hex -f nrf91 --sectorerase -r  --verify

I only receive

SPM: NS image at 0x8000

SPM: NS MSP at 0x2002a898

SPM: NS reset vector at 0xfda1

SPM: prepare to jump to Non-Secure image.

***** Booting Zephyr OS v1.14.99-ncs1-1066-gf210011b9609 *****

Application started

LTE LC config ...

Are we missing a couple of steps here as discussed yesterday?

Shouldn't I be loading SPM and downloading .elf first, because of the UICR and then reflashing the modem software then doing:?

nrfjprog --program 0535.jan_merged.hex -f nrf91 --sectorerase -r  --verify

Anyway the above non repeatable behavior regardless of the SPM thing seems similar to my experience with the NZ distributor that I spent several hours with yesterday, who were as always extremely helpful.

Between ourselves we had two different machines (Windows 10) using the MASTER branch of the software Segger 4.16 Both compiled the Asset Tracker.

With no changes to the merged.hex produced we were able to make three nrf9160-DK function as expected (begin pairing process) and by erasing the chip and loading SPM .elf and modem and same merged.hex fail whereby the pairing process was never initiated.

By doing as mentioned above I think we have eliminated (I hope) the tools and the application, as it would seem most unlikely that we were able to between ourselves make identical boards (version 0.8.5) vacillate between functioning as expected and failing reliably with the same merged.hex. We can only surmise and or conclude that it is something related to the UICR mechanism and or modem. which we have no control over.

On a completely different note:

I have noticed that sometimes (perhaps it's me) that my environment becomes unstable when I manipulate the versions using git checkout <tag> and west update to the point that I trash the directory and start again with the following:

mkdir ncs
cd ncs
west init -m github.com/.../fw-nrfconnect-nrf
west update

Then everything returns to normal for a while.

If I may make a suggestion, as it seems that most users will be using either 
the MASTER branch or a tagged release of their choice that to avoid/eliminate any 
possible corruption potentially caused by Git or West that it would be really
simple to upload relevant zips (in the usual format) of the tagged releases on the 
Nordic website?

The software is complex enough without having to absolutely rely upon the various
scripts involved to hopefully deliver the correct version of the software, which 
currently from my own experience, without grumbling about Git or anyone else
most certainly doesn't seem as reliable as it should/could be.
:)

[Martin Lesund]

Hi John,

• Please use the recommended v0.4.0 tag

How to get the v0.4.0 tag of NCS:

cd ncs/ncs
git checkout master
git pull
git checkout v0.4.0
west update

Then you do not need to worry about any other versions since this is a stable release. (it is not recommended to use the master branch)

• Program the Asset Tracker sample

Programming Asset Tracker tutorial

If you have provisioned other keys to the modem flash you have overwritten the already pre-provisioned nrf cloud credentials which can be the reason why you cannot connect to the nrf cloud. If you can run the standard mqtt_simple sample and see that you get the expected result : https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/mqtt_simple/README.html

Then this is most likely the reason why you cannot access the nrf cloud.

If that is the case we can send you the certificates over a Direct message if you want to connect to the nrf cloud with your nrf91DK.

---

Please go through the nRF Connect SDK tutorial which will answer your other questions: https://devzone.nordicsemi.com/nordic/cellular-iot-guides/b/getting-started-cellular/posts/nrf-connect-sdk-tutorial

---

Please disregard the UICR.hex since the same functionality has been implemented in the spm. 

Best Regards,
Martin L.