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,

     

    Ivan Popov said:
    there are Thingy:91 related code samples, like the asset_tracker_v2, which I can not for reasons related to boot partitioning layout/size?

    No, this is due to the added CONFIG_SECURE_BOOT=y on your side. This will add the immutable bootloader as a child-image to the build, which is not compatible with the thingy91 board.

    These are by default disabled for the thingy91 board via the overloaded .conf file here:

    https://github.com/nrfconnect/sdk-nrf/blob/main/applications/asset_tracker_v2/boards/thingy91_nrf9160_ns.conf#L30-L32

    Ivan Popov said:
    How the first groups of code samples is not affected by the limitation of the second one?

    This is because other samples has CONFIG_SECURE_BOOT=n.

    Ivan Popov said:
    Can I use the aws_iot code sample, tweak it a bit (add the parts of the code from the asset tracker which gather and report the sensors data - which is where exactly in the code-tree?) and flash that program on the Thingy:91?

    If you ensure that CONFIG_SECURE_BOOT is not set, then it shall compile without any problems.

     

    Kind regards,

    Håkon

  • 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

  • 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

  • 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

  • Hi Ivan,

     

    Thank you for summarizing. I'm glad to hear that you got things working with a newer version. 

    Ivan Popov said:
    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?

    If you have a working setup with a newer NCS version, I would recommend that you go forward with this one.

     

    Kind regards,

    Håkon

Reply
  • Hi Ivan,

     

    Thank you for summarizing. I'm glad to hear that you got things working with a newer version. 

    Ivan Popov said:
    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?

    If you have a working setup with a newer NCS version, I would recommend that you go forward with this one.

     

    Kind regards,

    Håkon

Children
No Data
Related