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

I can still execute commands though. If I put AT%CMNG=1 and press enter it either returns 'ERROR', or properly gives me the list of the provisioned certificates ...

Ah, so the problem is that the at_client is grabbing the uart interface, and logs are not printed.

The uart itself actually works, but not as intended.

 

Could you share your full configuration?

In order for the logging to output over serial, you will need to have these set:

CONFIG_LOG=y
CONFIG_LOG_BACKEND_UART=y
CONFIG_UART_CONSOLE=y
CONFIG_CONSOLE=y

 

 

Ivan Popov said:

I suspect it could be related to toolchain paths but I can be wrong.
To be exhaustive:

This is a direct impact of thingy91 board effectively not supporting CONFIG_SECURE_BOOT, unfortunately.

Ivan Popov said:

So far I've always flashed the built apps according to the rules in the documentation (pressed SW3 while switching on SW1, and MCU Boot option switched ON) ... So far I haven't had a case where in the Programmer the green area (the image layout reaches above the half of the designated area (assuming 100% is to the top)).

But in this case I can't know - the build fails and I don't get to the HEX image to flash. 

Do you mean that the build is limited to a specific memory size and would fail if the image gets calculated to become larger?

The root problem is that thingy91_nrf9160_ns board is statically setup without having the b0 partition support. The flash layout of thingy91 is effectively set in stone by the formerly linked thingy91_pm_static.yml

 

The fix would be to create a completely new board, based on the thingy91 or nrf9160dk board, unfortunately.

thingy91 is not a pure development platform, but rather a prototyping platform, and it has its restrictions in this sense.

 

Kind regards,

Håkon