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,

 

Ivan Popov said:

... and since the problem is already different from the one in the title of the ticket, I'm not very sure if I have to close this and open another one, or we just can finish this here?

No worries, let's continue here.

Ivan Popov said:

As for the brltty problem - I've had it before with another device (as you can see from my answer here), and I've removed it some time ago.

Glad to hear that you got that one sorted out.

This was something I had completely forgotten about myself, until I recently got a new computer at work; and then ran into it again.

 

Ivan Popov said:

And here is output in the Serial Terminal (from the file) (the aws_iot sample is flashed on the device):

Still no visible output on ttyACM0? Same thing with other serial consoles, like putty/minicom etc? Could you uncheck the hardware flow control, to ensure it is off?

Ivan Popov said:

device is visible in AWS, so I assume the sample works and the communication can be maintained through MQTT;

This is good.

 

Ivan Popov said:

the build for the sample fails with the only change to it being the addition of the AWS properties in the respective overlay file (overlay-aws.conf) and the error is addressed in this ticket too:

This has references to subimage "b0" - do you have CONFIG_SECURE_BOOT=y set in your current configuration? Thingy91 is applying a pm_static.yml file, as it expects a certain layout in order for the bootloader over serial to work, which does not include the b0 immutable bootloader, which is automatically attached as a sub-image when setting CONFIG_SECURE_BOOT=y.

Here's the default pm_static it applies for each project:

https://github.com/nrfconnect/sdk-nrf/blob/main/boards/arm/thingy91_nrf9160/thingy91_pm_static.yml

 

When b0 is added, which is a first-stage bootloader for mcuboot, you will not be able to fit the image onto the flash, as it conflicts with what is statically defined in the above file.

 

Kind regards,

Håkon

[Ivan Popov]

Hello Håkon,

Your questions caught me a bit uneducated, so I had to see a few things before replying.

Some answers:

Håkon Alseth said:

Still no visible output on ttyACM0?

No. The only three lines I get in the ST's log when I select the Thingy are:

11:11:42.567

Selected device with s/n THINGY91_EFF429E9883D

11:11:42.614

Opened port with options: {"baudRate":115200,"path":"/dev/ttyACM0"}

11:11:42.638

Get terminal settings from persistent store THINGY91_EFF429E9883D.vCom-0.TerminalSettings

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 ...

Håkon Alseth said:

Same thing with other serial consoles, like putty/minicom etc?

Haven't tried before. With Putty (the following settings - default for the ST too) nothing happens when I click 'Open':

Minicom is completely new for me, and I'd need some time with it in order to get used to it.

Håkon Alseth said:

Could you uncheck the hardware flow control, to ensure it is off?

I'm not sure how to do that.

Håkon Alseth said:

This has references to subimage "b0" - do you have CONFIG_SECURE_BOOT=y set in your current configuration?

I suppose this is the default and I haven't touched it:

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?

Regards,

Ivan Popov

[Ivan Popov]

I'm putting here the output of the actual build:

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

• I started with the Thingy at version 2.4.0 of the SDK (it generated a toolchain with the same version back then);
• Then when this use case came around the SDK was already updated at 2.4.2;
• When the build failed for the first time I noticed that the toolchain remained at version 2.4.0 - regenerated it and it moved to version 2.4.2 but:
  • the build failed the same way;
  • and when I compared the two toolchain directories they both had absolutely the same content.

[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

[Ivan Popov]

Hello Håkon,

Thanks for this answer, it clears a bit my perspective but I still need to clear up something.

So

• there are Thingy:91 related code samples, like the aws_iot, the blinky, etc., which I can build and flash on the board (and I obviously did) and then 
• there are Thingy:91 related code samples, like the asset_tracker_v2, which I can not for reasons related to boot partitioning layout/size?

This brings for me at least the following two questions:

• How the first groups of code samples is not affected by the limitation of the second one?
• 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?

I mean, am I missing something something in this perspective?

Best regards,

Ivan