Testing Location Sample Using Custom nrf9160 Boards Failed

[tonyl02]

Hi, I was trying to test the location sample on my custom board that has an nrf9160 chip. I did everything in this link: https://docs.nrfcloud.com/Guides/GettingStarted/Devices/#securely-generating-credentials-on-the-nrf9160, but when I tried to run the nrf Location sample, it gave me this error:

When I was following the steps described in the "securely generating credentials on the nRF9160" section in https://docs.nrfcloud.com/Guides/GettingStarted/Devices/#securely-generating-credentials-on-the-nrf9160, for step 6, the AT command I was sending to my custom boards over UART was "AT%CMNG=0,16842753,1,\"-----BEGIN CERTIFICATE-----\r\nMIIBZjCCAQ0CFEIJ8...-----END CERTIFICATE-----\"\r\n", so I was using \r\n to indicate line breaks in the certificate pem file, and I also used \r\n to indicate the end of an AT command, and I was wondering if this is ok.

Besides, for step 8, I was wondering if I need to provision the devices using the "ProvisionDevices" endpoint, and my device needs to appear and be connected on the nRF cloud, in order for the location sample to work. Since I noticed the location sample only uses the nRF cloud REST API, I only registered the public key using the "RegisterPublicKeys" endpoint. Also I didn't specify my nRF cloud API key and my device ID in my location sample codes , and I was wondering if that is what caused the program to fail.

Following the steps in https://docs.nrfcloud.com/Guides/GettingStarted/Devices/#securely-generating-credentials-on-the-nrf9160 is pretty much all I did. I didn't update my modem firmware on my custom boards, since I am not sure how to do that without using the Programmer app in nRF Connect for Desktop. But I doubt that is what caused the issue.

Sorry for this long question, but I am not sure what I did wrong in the process, so I figured I'd be more detailed. If you need any other information, please let me know.

[Didrik Rokhaug]

Hi,

When you provisioned the credentials to the device, did you include the <CR><LF> at the end? (it is also a part of the certificate, and must be included).

Which device ID did you use when you added the device to nRF Cloud? Did the device appear in nRF Cloud?

The error code indicates that something went wrong during the TLS handshake, which caused the server to reject the connection. If you take a modem trace, then I can look further into why the connection was refused.

Best regards,

Didrik

[tonyl02]

I apologize, I didn't realize that the function SEGGER_RTT_WriteSkipNoLock is actually defined to be SEGGER_RTT_ASM_WriteSkipNoLock. However, it seems like the function has only been declared in SEGGER_RTT.h and doesn't get defined anywhere, which results in this error. I was wondering if this is potentially a bug.

Besides, I was still wondering if my prj.conf file is ok, in particular the CONFIG_USE_SEGGER_RTT, which I set to y. It seemed like even if I set it to n, it would still have the value y during compilation.

[Didrik Rokhaug]

The CONFIG_USE_SEGGER_RTT is not a problem, in fact, it is required for RTT to work in the first place.

The compile error comes from CONFIG_LOG_BACKEND_RTT=n. The good news however is that you don't need to disable it. If you set it back to "y", it should work.

[tonyl02]

Thank you for the suggestion! I got the modem trace in a bin file. Please let me know if it helps. modem-trace.bin

[Didrik Rokhaug]

Thanks. Unfortunately, the trace wasn't much help. I could not find the parts that I was interested in.

In general, tracing over RTT is less stable than tracing over UART (I believe we are working on improving that), so it might be that the interesting parts were simply dropped.

Another possibility is that they occurred before you were able to connect the RTT client, or if you did a reset of the device after connecting, that would also have disconnected the client.

Could you try to take another one, this time with a long (enough) delay (for you to connect the RTT client and start logging to a file) at the beginning of main()?

I will also try to reproduce the error at my end.

P.s. I will be out of office tomorrow, and unable to reply until Monday.

[Didrik Rokhaug]

Hi, have you been able to take a new modem trace?

I went through this guide: https://docs.nrfcloud.com/Guides/GettingStarted/Devices#securely-generating-credentials-on-the-nrf9160

Using the modem UUID as the device ID as I did not specify another ID in the %KEYGEN command.

In step 7, I wrote this CA certificate: https://www.amazontrust.com/repository/AmazonRootCA1.pem

As well as the <uuid>_crt.pem file created by the create_device_credentials.py script.

I then registered the <uuid>_pub.pem public key with the devices/public-keys API endpoint

curl -X POST https://api.nrfcloud.com/v1/devices/public-keys --data-binary @<uuid>.csv -H "Content-Type: application/oct
et-stream" -H "Authorization: Bearer <API key>"

The <uuid>.csv file was formatted as shown in the API documentation: https://api.nrfcloud.com/v1/#tag/IP-Devices/operation/RegisterPublicKeys

Finally, I added the following config options to the prj.conf of the location sample:

CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y
CONFIG_NRF_MODEM_LIB_TRACE_ENABLED=y
CONFIG_NRF_CLOUD_SEC_TAG=16842740

(I did the test on my DK, which is already registered with nRF Cloud with the IMEI as the ID on the default sec tag. I therefor used a different sec_tag, including when using the %KEYGEN AT command. Enabling modem tracing is just for debugging purposes. But I wanted to list them here for completeness)

After going through the above steps, the location sample worked as it should for me:

*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
Location sample started

Connecting to LTE...
+CEREG: 2,"76C1","014ACE00",7
+CSCON: 1
+CEREG: 1,"76C1","014ACE00",7,,,"00000100","10111110"
Connected to LTE
Waitin%XTIME: ,"22905051308080","01"
g for current time
Requesting location with short GNSS timeout to trigger fallback to cellular...
+CSCON: 0
[00:00:16.263,214] [1B][1;33m<wrn> location: Timeout occurred[1B][0m
[00:00:16.275,634] [1B][1;33m<wrn> location: Failed to acquire location using 'GNSS', trying with 'Cellular' next[1B][0m
%NCELLMEAS: 0,"014ACE00","24201","76C1",98,6400,247,55,24,16463,300,425,29,24,23,13517
+CSCON: 1
Got location:
  method: Cellular
  latitude: 63.418751
  longitude: 10.431030
  accuracy: 215.0 m
  date: 2022-09-05
  time: 15:03:22.359 UTC
  Google maps URL: https://maps.google.com/?q=63.418751,10.431030