Testing Location Sample Using Custom nrf9160 Boards Failed

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Fri, 09 Sep 2022 12:18:21 GMT

[quote user="tonyl02"]I did notice that in the mqtt_simple sample the line breaks in credentials are represented using "\n", but when I flashed the credentials I used "\r\n". Is this something that could cause the issue?[/quote]

If I write a certificate to the modem with the Certifiate Manager, it also uses <CR><LF>, same when I read the certificate out from the modem, so I don't think that is the issue.

Regardless, I still suspect there could be something wrong with your credentials. Could you try to write them from the application, or read out the CA certificate to confirm that it was written correctly?

And pay particular attention to the line endings, including the one at the end, after the "-----END CERTIFICATE-----"

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Thu, 08 Sep 2022 22:27:42 GMT

I actually wrote the certificates using AT commands through STM32. And the CA credential that I used is: https://www.amazontrust.com/repository/AmazonRootCA1.pem, and the device credential is the one that is generated using the create_device_credentials.py script. I did notice that in the mqtt_simple sample the line breaks in credentials are represented using "\n", but when I flashed the credentials I used "\r\n". Is this something that could cause the issue?

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Wed, 07 Sep 2022 12:01:38 GMT

Thanks, this trace is a lot better (still not perfect, but that is probably due to the RTT transport).

I haven't been able to find anything directly wrong yet, but the length of our certificates (both CA and the device's) has significant different sizes.

How did you write the certificates to the device?

If you write them from the code, you can see an example of how it can be done in the mqtt_simple sample. There, they have a CA certificate correctly formatted in the certificates.h file, and they use the modem_key_mgmt_write function to write it to the modem in the certificates_provision funtion in main.c.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Wed, 07 Sep 2022 00:00:18 GMT

I apologize for the late reply. I have taken another modem trace. I waited for one hour or so before I stopped logging, so hopefully this time it'll help.

devzone.nordicsemi.com/.../modem_2D00_trace-_2800_2_2900_.bin

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Mon, 05 Sep 2022 15:16:53 GMT

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

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Thu, 01 Sep 2022 12:33:35 GMT

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.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Tue, 30 Aug 2022 20:10:10 GMT

Thank you for the suggestion! I got the modem trace in a bin file. Please let me know if it helps. devzone.nordicsemi.com/.../modem_2D00_trace.bin

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Tue, 30 Aug 2022 14:47:58 GMT

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.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Mon, 29 Aug 2022 23:11:41 GMT

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.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Mon, 29 Aug 2022 20:12:39 GMT

After adding the lines that you mentioned into my prj.conf and compiling the program, it gave me this error:

However, I looked into the nrf_modem_lib_trace_sync.c file, and I actually didn't find any reference to the SEGGER_RTT_ASM_WriteSkipNoLock function, and instead I only found SEGGER_RTT_WriteSkipNoLock function, so I am very connfused as to what this error is complaining about:

Besides, in my prj.conf, in addition to adding CONFIG_NRF_MODEM_LIB_TRACE_ENABLED=y, CONFIG_NRF_MODEM_LIB_TRACE_MEDIUM_RTT=y, CONFIG_LOG_BACKEND_RTT=n, and CONFIG_RTT_CONSOLE=n, there was also a line CONFIG_USE_SEGGER_RTT=y, and it doesn't seem like it could be set to n. I was curious if having this line in my prj.conf is ok.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Mon, 29 Aug 2022 12:34:32 GMT

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.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Fri, 26 Aug 2022 19:04:18 GMT

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.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Fri, 26 Aug 2022 08:37:39 GMT

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

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Thu, 25 Aug 2022 22:43:29 GMT

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

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Wed, 24 Aug 2022 08:24:59 GMT

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?

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Tue, 23 Aug 2022 18:58:54 GMT

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.

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Tue, 23 Aug 2022 15:09:47 GMT

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?

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

tonyl02 — Thu, 18 Aug 2022 19:31:11 GMT

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?

RE: Testing Location Sample Using Custom nrf9160 Boards Failed

Didrik Rokhaug — Wed, 17 Aug 2022 16:57:40 GMT

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