changing the tracker application to aws_iot gives hard crash

[savenlid]

I just brute force changed to "AWS_IOT", having the keys , and other config already in place after having tried the cloud sample code successfully against AWS

main.c

line 1160:

cloud_backend = cloud_get_binding("AWS_IOT");  // was "NRF_CLOUD"

prj.conf:

# Generic cloud API
CONFIG_CLOUD_API=y  ( maybe this one should be=n or removed, it confusing that 3 simultaneous clouds are in action at the same time)

# nRF Cloud
CONFIG_NRF_CLOUD=y  ( maybe this one should be =n or removed ?? )

CONFIG_AWS_IOT=y

It works fine until it publish to shadow.

I understand that my work as a programmer is to make things work, but even if I abused the library I think a crash is not a graceful error handling by the lib.

Also the tracker app for me is much more useful against a real open cloud I can use in production and not nrfcloud.

2020-03-18T15:00:35.480Z DEBUG modem << *** Booting Zephyr OS build v2.1.99-ncs1 ***\x0D
2020-03-18T15:00:35.490Z DEBUG modem << [00:00:00.190,887] \x1B[0m<dbg> nrf9160_gps.init: MAGPIO set: AT%XMAGPIO=1,0,0,1,1,1574,1577\x1B[0m\x0D\x0A
2020-03-18T15:00:35.498Z DEBUG modem << [00:00:00.199,768] \x1B[0m<dbg> nrf9160_gps.init: COEX0 set: AT%XCOEX0=1,1,1570,1580\x1B[0m\x0D
2020-03-18T15:00:35.506Z DEBUG modem << [00:00:00.207,489] \x1B[0m<inf> asset_tracker: Asset tracker started\x1B[0m\x0D\x0A
2020-03-18T15:00:35.512Z DEBUG modem << [00:00:00.214,447] \x1B[0m<inf> asset_tracker: Connecting to LTE network. \x1B[0m\x0D\x0A
2020-03-18T15:00:35.522Z DEBUG modem << [00:00:00.221,282] \x1B[0m<inf> asset_tracker: This may take several minutes.\x1B[0m\x0D\x0A
2020-03-18T15:00:35.539Z DEBUG modem << [00:00:00.236,328] \x1B[0m<dbg> lte_lc.w_lte_lc_connect: Network mode: AT%XSYSTEMMODE=1,0,1,0\x1B[0m\x0D\x0A
2020-03-18T15:00:37.121Z DEBUG modem << +CEREG: 2,"8502","04CB7C0A",7,0,0,"11100000","11100000"\x0D\x0A
2020-03-18T15:00:37.140Z DEBUG modem << [00:00:01.831,237] \x1B[0m<dbg> lte_lc.parse_nw_reg_status: Network registration status: 2\x1B[0m\x0D\x0A
2020-03-18T15:00:41.566Z DEBUG modem << +CEREG: 5,"8502","04CB7C0A",7,,,"11100000","11100000"\x0D\x0A
2020-03-18T15:00:41.574Z DEBUG modem << [00:00:06.274,688] \x1B[0m<dbg> lte_lc.parse_nw_reg_status: Network registration status: 5\x1B[0m\x0D\x0A
2020-03-18T15:00:41.579Z DEBUG modem << [00:00:06.283,142] \x1B[0m<inf> asset_tracker: Connected to LTE network\x1B[0m\x0D
2020-03-18T15:00:46.718Z DEBUG modem << [00:00:11.420,623] \x1B[0m<dbg> aws_iot.broker_init: IPv4 Address found 52.41.13.123\x1B[0m\x0D\x0A
2020-03-18T15:01:02.112Z DEBUG modem << [00:00:26.813,354] \x1B[0m<inf> aws_jobs: Subscribe: $aws/things/nrf-352656100377954/jobs/notify-next\x1B[0m\x0D\x0A
2020-03-18T15:01:02.127Z DEBUG modem << [00:00:26.823,944] \x1B[0m<inf> aws_jobs: Subscribe: $aws/things/nrf-352656100377954/jobs/$next/get/#\x1B[0m\x0D\x0A
2020-03-18T15:01:02.132Z DEBUG modem << [00:00:26.834,075] \x1B[0m<dbg> aws_iot.mqtt_evt_handler: MQTT client connected!\x1B[0m\x0D\x0A
2020-03-18T15:01:02.144Z DEBUG modem << [00:00:26.841,491] \x1B[0m<dbg> aws_iot.topic_subscribe: Subscribing to AWS shadow topic: $aws/things/nrf-352656100377954/shadow/get/accepted\x1B[0m\x0D\x0A
2020-03-18T15:01:02.156Z DEBUG modem << [00:00:26.854,278] \x1B[0m<dbg> aws_iot.topic_subscribe: Subscribing to AWS shadow topic: $aws/things/nrf-352656100377954/shadow/get/rejected\x1B[0m\x0D
2020-03-18T15:01:02.169Z DEBUG modem << [00:00:26.867,034] \x1B[0m<dbg> aws_iot.topic_subscribe: Subscribing to AWS shadow topic: $aws/things/nrf-352656100377954/shadow/update/accepted\x1B[0m\x0D\x0A
2020-03-18T15:01:02.182Z DEBUG modem << [00:00:26.880,035] \x1B[0m<dbg> aws_iot.topic_subscribe: Subscribing to AWS shadow topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D
2020-03-18T15:01:02.191Z DEBUG modem << [00:00:26.894,165] \x1B[0m<inf> asset_tracker: CLOUD_EVT_CONNECTED\x1B[0m\x0D\x0A
2020-03-18T15:01:02.195Z DEBUG modem << [00:00:26.900,268] \x1B[0m<inf> asset_tracker: CLOUD_EVT_READY\x1B[0m\x0D
2020-03-18T15:01:02.210Z DEBUG modem << [00:00:26.906,860[00:00:26.908,966] \x1B[0m<dbg> aws_iot.aws_iot_send: Publishing to topic: $aws/things/nrf-352656100377954/shadow/update\x1B[0m\x0D\x0A
2020-03-18T15:01:02.220Z DEBUG modem << ] \x1B[0m<inf> [00:00:26.921,325] \x1B[1;31m<err> os: ***** USAGE FAULT *****\x1B[0m\x0D\x0A
2020-03-18T15:01:02.223Z DEBUG modem << [00:00:26.927,062] \x1B[1;31m<err> os: Unaligned memory access\x1B[0m\x0D\x0A
2020-03-18T15:01:02.231Z DEBUG modem << [00:00:26.933,013] \x1B[1;31m<err> os: r0/a1: 0x000fffff r1/a2: 0x0000000f r2/a3: 0x000fffff\x1B[0m\x0D\x0A
2020-03-18T15:01:02.244Z DEBUG modem << [00:00:26.941,833] \x1B[1;31m<err> os: r3/a4: 0x2002d6ac r12/ip: 0x20024b38 r14/lr: 0x0001e977\x1B[0m\x0D\x0A
2020-03-18T15:01:02.246Z DEBUG modem << [00:00:26.950,653] \x1B[1;31m<err> os: xpsr: 0xa102b800\x1B[0m\x0D\x0A
2020-03-18T15:01:02.260Z DEBUG modem << [00:00:26.955,963] \x1B[1;31m<err> os: s[ 0]: 0x00000001 s[ 1]: 0x00000001 s[ 2]: 0x00000001 s[ 3]: 0x00000001\x1B[0m\x0D\x0A
2020-03-18T15:01:02.267Z DEBUG modem << [00:00:26.966,522] \x1B[1;31m<err> os: s[ 4]: 0x00000001 s[ 5]: 0x00000001 s[ 6]: 0x00000001 s[ 7]: 0x00000001\x1B[0m\x0D\x0A
2020-03-18T15:01:02.278Z DEBUG modem << [00:00:26.977,111] \x1B[1;31m<err> os: s[ 8]: 0x00000001 s[ 9]: 0x00000001 s[10]: 0x00000001 s[11]: 0x00000001\x1B[0m\x0D\x0A
2020-03-18T15:01:02.293Z DEBUG modem << [00:00:26.987,701] \x1B[1;31m<err> os: s[12]: 0x00000001 s[13]: 0x00000001 s[14]: 0x00000001 s[15]: 0x00000001\x1B[0m\x0D\x0A
2020-03-18T15:01:02.295Z DEBUG modem << [00:00:26.998,291] \x1B[1;31m<err> os: fpscr: 0x00000000\x1B[0m\x0D\x0A
2020-03-18T15:01:02.302Z DEBUG modem << [00:00:27.003,601] \x1B[1;31m<err> os: Faulting instruction address (r15/pc): 0x00038bae\x1B[0m\x0D\x0A
2020-03-18T15:01:02.311Z DEBUG modem << [00:00:27.011,627] \x1B[1;31m<err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0\x1B[0m\x0D\x0A
2020-03-18T15:01:02.316Z DEBUG modem << [00:00:27.019,592] \x1B[1;31m<err> os: Current thread: 0x200237e4 (unknown)\x1B[0m\x0D\x0A
2020-03-18T15:01:02.332Z DEBUG modem << [00:00:27.026,489] \x1B[1;31m<err> asset_tracker: Running main.c error handler\x1B[0m\x0D\x0A
2020-03-18T15:01:02.334Z DEBUG modem << *** Booting Zephyr OS build v2.1.99-ncs1 ***\x0D\x0A

[savenlid]

ps

forgot to mention that i did not find docs on "cloud_release_data"

ds

[Øyvind]

Hello, 

Can you please explain what you are trying to do? We do not recommend editing the asset_tracker application but rather start with a simpler sample e.g. Simple MQTT or AWS FOTA

Kind regards,
Øyvind

[Markus Tacker (he/him)]

We found an issue with the aws-iot sample where to cJSON library was not initialized correctly, which leads to the crash.

This is addressed in this PR: https://github.com/NordicPlayground/fw-nrfconnect-nrf/pull/2035

If you apply this fix (and you have followed the setup procedure for your AWS account correctly) the crash should no longer happen.

[Øyvind]

Thanks for clarifying Markus Tacker (he/him)!

savenlid please follow instructions given and let me know how that works. 

Kind regards,
Øyvind

[savenlid]

Yes, works,

But I get rejections on my postings to shadow

But thats because I am a newbie to MQTT etc

I will study and fix.

Thanks a lot

2020-03-19T15:24:52.151Z DEBUG modem << [00:01:00.230,926] \x1B[0m<dbg> aws_iot.aws_iot_send: Publishing to topic: $aws/things/nrf-352656100377954/shadow/update\x1B[0m\x0D\x0A
2020-03-19T15:24:52.170Z DEBUG modem << [00:01:00.250,000] \x1B[0m<dbg> aws_iot.aws_iot_send: Publishing to topic: $aws/things/nrf-352656100377954/shadow/update\x1B[0m\x0D\x0A
2020-03-19T15:24:52.183Z DEBUG modem << [00:01:00.262,664] \x1B[0m<dbg> aws_iot.aws_iot_send: Publishing to topic: $aws/things/nrf-352656100377954/shadow/update\x1B[0m\x0D\x0A
2020-03-19T15:24:52.778Z DEBUG modem << [00:01:00.856,018] \x1B[0m<dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D\x0A
2020-03-19T15:24:52.791Z DEBUG modem << [00:01:00.867,523] \x1B[0m<inf> aws_fota: received an unhandled MQTT publish event on topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D\x0A
2020-03-19T15:24:52.798Z DEBUG modem << [00:01:00.880,889] \x1B[0m<dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 1 len = 53 \x1B[0m\x0D\x0A
2020-03-19T15:24:52.809Z DEBUG modem << [00:01:00.890,258] \x1B[0m<inf> asset_tracker: CLOUD_EVT_DATA_RECEIVED\x1B[0m\x0D\x0A
2020-03-19T15:24:52.846Z DEBUG modem << [00:01:00.924,224] \x1B[0m<dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D\x0A
2020-03-19T15:24:52.859Z DEBUG modem << [00:01:00.935,760] \x1B[0m<inf> aws_fota: received an unhandled MQTT publish event on topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D\x0A
2020-03-19T15:24:52.868Z DEBUG modem << [00:01:00.949,127] \x1B[0m<dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 2 len = 53 \x1B[0m\x0D\x0A
2020-03-19T15:24:52.877Z DEBUG modem << [00:01:00.958,374] \x1B[0m<inf> asset_tracker: CLOUD_EVT_DATA_RECEIVED\x1B[0m\x0D\x0A
2020-03-19T15:24:52.893Z DEBUG modem << [00:01:00.965,332] \x1B[0m<dbg> aws_fota.on_publish_evt: Received topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D\x0A
2020-03-19T15:24:52.900Z DEBUG modem << [00:01:00.976,898] \x1B[0m<inf> aws_fota: received an unhandled MQTT publish event on topic: $aws/things/nrf-352656100377954/shadow/update/rejected\x1B[0m\x0D\x0A
2020-03-19T15:24:52.909Z DEBUG modem << [00:01:00.990,234] \x1B[0m<dbg> aws_iot.mqtt_evt_handler: MQTT_EVT_PUBLISH: id = 3 len = 53 \x1B[0m\x0D\x0A
2020-03-19T15:24:52.916Z DEBUG modem << [00:01:00.999,633] \x1B[0m<inf> asset_tracker: CLOUD_EVT_DATA_RECEIVED\x1B[0m\x0D\x0A

[Markus Tacker (he/him)]

You can subscribe to $aws/things/nrf-352656100377954/shadow/update and $aws/things/nrf-352656100377954/shadow/update/rejected to see why it's getting reject on your AWS accounts IoT console to see the messages and rejections.

[savenlid]

Thanks, I did that, and rewrote the code that reports up to the shadow for the temperature etc.

It was code 400, missing "state", i dont know anything about the nrf_cloud, but seems the format was different.

Now the problem now for me is that SES and I are not in agreement.
I need to write another ticket ( or 4 ) on that.

1:
It does not think I can set an breakpoint because there is no code where it obviously is.

2:
Also SES needs to rebuild every time before debug even tough nothing has changed.

3:
Every now and then SES missed some hw_info file.

4:

Also SES seems to ignore the prj.conf that does not propagate into kconfig in the build directory, but this works fine when building from the prompt.

https://devzone.nordicsemi.com/f/nordic-q-a/59326/prj-conf-definition-is-not-activated-on-ses

So... a lot of problem with SES for me :-)