Weird output from serial port

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

Parents
  • Hi Håkon,

    Since I've read in many places that the only limitation for the SEC_TAG's value is to be different than the one reserved for the nRF Cloud (the one already filled in when you open the Certificate Manager), I've used different values. But I've always been careful to keep the tag the same in both the certificates I provision, and the code sample I'm building (in the prj.conf).

    So now I just returned the value everywhere to 201, reprovisioned the three certificates the same way you describe it, and flashed the newly built app_signed.hex file. The result unfortunately was all the same:

    If I'm missing something I already have no idea what it might be ...

    Actually, I noticed something at some point. I'm not sure if it is relevant at all but at in all other cases we had (with other types of devices, including virtual ones - python scripts) it was always mandatory to specify the default secure MQTT port (8883). I've never found a related property in the code samples - is it something hardcoded deeper in the firmware?

    Best regards,

    Ivan

Reply
  • Hi Håkon,

    Since I've read in many places that the only limitation for the SEC_TAG's value is to be different than the one reserved for the nRF Cloud (the one already filled in when you open the Certificate Manager), I've used different values. But I've always been careful to keep the tag the same in both the certificates I provision, and the code sample I'm building (in the prj.conf).

    So now I just returned the value everywhere to 201, reprovisioned the three certificates the same way you describe it, and flashed the newly built app_signed.hex file. The result unfortunately was all the same:

    If I'm missing something I already have no idea what it might be ...

    Actually, I noticed something at some point. I'm not sure if it is relevant at all but at in all other cases we had (with other types of devices, including virtual ones - python scripts) it was always mandatory to specify the default secure MQTT port (8883). I've never found a related property in the code samples - is it something hardcoded deeper in the firmware?

    Best regards,

    Ivan

Children
No Data
Related