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

[Ivan Popov]

Hi Håkon,

Could you please provide a procedure for provisioning the certificates that is correct? Because out of the several variants available in different part of the Nordic documentation, so far nothing changes the end result and I always end up with the ENOTCONN (-128) error which according to its comment is related to some socket and not with the credentials (I saw many cases where people get error 111, regarding the credentials). 

I worked exclusively with the Certificate Manager (in the Cellular Monitor application) and rewrote the certificates several times with:

• different security tags (never the one reserved for the nRF Cloud)
• with and without an empty new line after the closing line (-----END CERTIFICATE-----)
• I even tried to add them into the dedicated files in the source tree (perfectly realising that this is most probably a deprecated practice)

Beyond that I tried your proposal:

Håkon Alseth said:

Note that you should set your client id + hostname according to the AWS IoT settings, similar to this (XXYYZZ11 used as example here):

although it doesn't make sense for the following reasons:

• As AWS describe it in their own documentation - the first part of the broker host name is "an account specific prefix" and can't be matched to an individual devise (but even it it could then which one of the myriad registered devices?)
• In our system we've registered so far some other types of devices too and the and it always worked this way: the Client ID is the unique ID given to the device by the AWS IoT Core registry and the broker host name is an MQTT endpoint for all the devices to connect to and is expected to always have the same constant value.

Eventually, I'm still revolving around this state:

and wonder how this socket connection requirement can be satisfied.

Best regards,

Ivan