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]

Hello, I ensured all of my <CR><LF> are correct. I used the UUID as the device ID. The device never appeared in the cloud. I tried the process again on a second device, and it did not appear in nRF Cloud. Then I provisioned the second device using the ProvisionDevices API endpoint and it now appears in the cloud. However, I still get the same error on the Location sample. I ran the Asset Tracker v2 sample, and the device appears offline in the nRF Cloud. I'm unable to use Modem Trace on our custom board because we do not have an external UART connection, only J-Link. I also generated a Service Evaluation Token, but I have not used this anywhere. Am I supposed to include the Evaluation Token somewhere in the Location sample?

[Didrik Rokhaug]

You should not need to add the evaluation token to the sample. I believe it is only used when sending requests to nRF Cloud frome something which is not an nRF9160.

But, if you are not able to connect to nRF Cloud when running the Asset Tracker v2 either, that would point to the device not being provisioned correctly.

What ID did you use when you created the credentials?

[tonyl02]

Thank you for your reply. I ran the command "AT%KEYGEN=16842753,2,0" to generate the private key in my custom board, and I believe it used the default device UUID as the device ID. When I ran the modem_credentials_parser.py script, I got my device ID as 50503041-3631-4b0e-806a-110adee04c62. On the second device I have, the device ID was 50503041-3631-47a5-80c9-2325a7abf643.

[Didrik Rokhaug]

The sample probably uses "nrf-<IMEI>" as the ID.

Could you try to set CONFIG_NRF_CLOUD_CLIENT_ID_SRC_INTERNAL_UUID=y in your prj.conf?

[tonyl02]

Unfortunately, that didn't work, and it still gave me the same error.

[Didrik Rokhaug]

Are you able to take a modem trace, so we can take a closer look at what goes wrong from a modem perspective?

[tonyl02]

Is there a way to do modem trace using J-Link by chance? Since our custom board doesn't have UART unfortunately, and therefore cannot use the trace collector.

[Didrik Rokhaug]

Yes, you can follow this guide to capture a modem trace over RTT:

1. Go into prj.conf and add these two lines:
CONFIG_NRF_MODEM_LIB_TRACE_ENABLED=y
CONFIG_NRF_MODEM_LIB_TRACE_MEDIUM_RTT=y

 

You might also need to disable other RTT logging channels:
CONFIG_LOG_BACKEND_RTT=n
CONFIG_RTT_CONSOLE=n

 

2. Compile and flash the project.

 

3. Open JLinkRTTViewer, select device "nRF9160_xxaa"

 

4. When successfully connected, go to "Logging" -> "Start Data Logging", and select a path to save the file.

 

5. See that the .log file grows in size. When finished tracing, stop data logging and rename the .log file to .bin

Note that this will disable application logging over RTT. You will just get the modem trace.