Weird output from serial port

[Ivan Popov]

Hello,

In short, my use case is that I'm trying to onboard a Thingy:91 to AWS IoT Core through the available code sample following this tutorial (and the related library description linked in it).

What I did successfully was: 

1. I managed to provision the certificates to the device (I can see them listed along with the default ones with the AT%CMNG=1 command).
2. I created a project from the sample (aws_iot), edited the required properties (AWS MQTT endpoint, device_id, topics, ...) and managed to build it in VSCode for the thingy91_nrf9160_ns target.
3. I flashed the resulting app_signed.hex file on the device with the Programmer application (it took ~50 seconds).

However, on rebooting the device in regular mode I get nothing in AWS IoT Core - nothing in the topics, nothing for the shadow.

I tried to get some clues from the serial terminal but all I get is a blank, black terminal. (Interestingly executing commands in the LTE Link Monitor is successful ...)

I tried to play a bit with the ports and their options but the only visible result was on the second (not the default for any of the previously (successfully) executed operations) port and it looked like the wrong Baud Rats was given:

Any ideas on how to proceed and how to determine what might be wrong? I've followed the tutorials as closely as possible, yet we're here.

Best regards,

Ivan Popov

[Håkon Alseth]

Hi Ivan,

 

I'm glad to hear that you were able to get a successful connection towards AWS!

Ivan Popov said:

Now this seems to resolve our problem and I see two further points to follow:

1. Modify the policy in order to make it more restrictive to the point where it has the minimum rights that let the device connect properly.
2. To see how to add the telemetry data from the sensors to the output ... I saw somewhere an example withe the older version of the Asset tracker (v1.6) - it probably should be enough. (I'd appreciate if you can confirm this.)

But these are further steps, and since we already have the basic connectivity I think the current issue is resolved. And if you don't have anything else to add I can close the ticket?

I just want to mention that there are some limited information on handling user data in this guide:

 Connecting to AWS cloud services using the nRF9160 

See the chapter named "Handling MQTT messages in AWS".

 

Kind regards,

Håkon

[Ivan Popov]

Thank you very much, Håkon!

On a first glance this guide looks promising - I'll dig into it.

Thanks for all your support and best of luck!

Best regards,

Ivan Popov

[Ivan Popov]

Hello Håkon,

I'm not reopening the ticket, I just have a thing to share. Last week after I switched to version 2.5 of the SDK and the toolchain I was already able to flash a customised version (AWS IoT enabled) of the Asset Tracker v2. The build passed successfully.

Any idea what have changed?

Best regards,

Ivan

[Håkon Alseth]

Hi Ivan,

 

Ivan Popov said:

I'm not reopening the ticket, I just have a thing to share. Last week after I switched to version 2.5 of the SDK and the toolchain I was already able to flash a customised version (AWS IoT enabled) of the Asset Tracker v2. The build passed successfully.

Any idea what have changed?

When you updated to ncs v2.5.0, did everything work as expected? Were you still having issues on ncs v2.4.x, and updating to ncs v2.5.0 fixes those issues?

 

Kind regards,

Håkon

[Ivan Popov]

Hi Håkon,

Let me summarise the issues I had while you were helping me:

1. The weird output in the Serial Terminal - it was quickly revealed that it was a misconfiguration on my side and I was trying to use an already occupied (or wrong) port.
2. The build failure of the Asset Tracker sample (with Thingy:91 as a target board) - the SDK/toolchain upgrade (to v.2.5.0) solved exactly that - this time the build failure just didn't happen and I was able to flash the resulting HEX file on the Thingy:91. As a result I'm able to see the default telemetries being uploaded to our system through the AWS IoT Core. Next step for me here is to enable the suppressed by default sampling of the ADXL362 accelerometer for the simplest possible use case but that is another story.
3. The inability of the Thingy:91 to connect to the AWS cloud despite the fact that everything was configured by-the-book - here you helped to find out that our certificate policy was too restrictive, and after fixing that I closed the ticket.

As for the sample build - after the build with the 2.5.0 version was successful I haven't tried to go back and test if would fail again with the 2.4.x versions - should I?

Regards,

Ivan