aws_iot sample

[Burt]

I am trying both v3.0.0 and v3.0.2 SDK; the board I am using is the nRF9160DK, version 1.1.0. There are 4 scenarios:

1) Run on Linux (minicom or Serial Terminal) following a power reset.

2) Run on Linux following a push button reset.

3) Same as 1) but under Windows using either Serial Terminal or Teraterm.

4) Same as 2) but under Windows; Serial Terminal or Teraterm.

1) functions fine although the boot messages are not seen.

2) shows the 3 lines of boot messages but then fails to display anything else.

3) fails completely to show any messages

4) behaves like 2). Boot messages are seen but nothing else.

The builds have all been done on Linux, but my colleague who is building on Windows is seeing the same behavior on Windows albeit he is using a custom board.  Thank you for a solution.

Regards,

Burt Silverman

ps v2.9.0 has the same problem. I'll have to get on my older machine to see if I can try older versions.

[Burt]

v2.5.0/nrf/samples/net/aws_iot works fine on Linux and I assume it will work fine on Windows. v2.7.0 works fine too. I did not try anything between v2.7.0 and v2.9.0 as I haven't downloaded anything in that range.

[Burt]

I just tried v2.8.0 and it failed. Then I looked at various changes that were made between v2.7.0 and v2.8.0. I found that commenting out 

CONFIG_SERIAL=n

in ...aws_iot/sysbuild/mcuboot/prj.conf

as has been done at v2.8.0 and I assume all releases following that does destroy the boot up sequence, or certainly at least the display of messages. (Ironic that you have to CONFIG_SERIAL=n to see UART output but that's what we see.)

Since somebody probably had a reason to make that change, on the one hand, and on the other hand it breaks the system, please have development look at this closely and give us the recommended fix. Thanks and regards,

Burt S.

[Burt]

Not really ironic because I see there is a new boot_banner library. But I don't understand why enabling CONFIG_SERIAL in mcuboot causes a problem for the application, other than you would see more boot messages than you want or need. Something tricky I guess.

[Achim Kraus]

I guess, using the serial for logging in mcuboot is in conflict with using the serial for the mcuboot rescue mode (CONFIG_MCUBOOT_SERIAL).

Additional the new sysbuild may require now, that the logging for the app itself is also more completely defined/configured.

At least I didn't get that irritations in the logging moving from 2.6.2 to 2.9.0.

About the observations:

Power On: both the app and the usb bridge are starting up simultaneously, so I don't wonder, that this may drop some early loggs when the app is starting faster than the usb bridge.

Windows: in my experience one nasty point was, that the COMx enumeration is sometimes mystic and you need to check, at which COM you get the log. Combined with issues in the logging itself, that will be pretty/too hard to test. I guess, once the logging works with linux again, it will be also easier to test, which COM interface is used for logging.

[Burt]

I have not heard anything from NS DevZone staff yet.