Kernel panic on nRF9151 when connecting to AWS

RE: Kernel panic on nRF9151 when connecting to AWS

Hakon — Sat, 14 Jun 2025 15:33:08 GMT

[quote user="Scott Grubb"]Is there another heap setting that I need to change? [/quote]

You can try increasing CONFIG_AT_MONITOR_HEAP_SIZE, if you haven't tried that already.

RE: Kernel panic on nRF9151 when connecting to AWS

Scott Grubb — Fri, 13 Jun 2025 09:57:51 GMT

I disabled CONFIG_ASSERT and now I can see that the problem is because there is insufficient heap space for an incoming notification. I have tried increasing the HEAP_MEM_POOL_SIZE to 65536 bytes but I'm still seeing the same message. Is there another heap setting that I need to change?

RE: Kernel panic on nRF9151 when connecting to AWS

Scott Grubb — Fri, 13 Jun 2025 07:39:31 GMT

Having said that, there is something odd going on within the aws_iot_connect() function. CONFIG_AWS_IOT_CONNECT_TIMEOUT is set to 30s by default, but it is taking around 150s for the connection attempt to timeout. It appears that the kernel panic always occurs on the second call to aws_iot_connect() after the first has timed out.

RE: Kernel panic on nRF9151 when connecting to AWS

Scott Grubb — Thu, 12 Jun 2025 23:48:35 GMT

Hi,

Thanks for the suggestions.

I had a read through the discussion you linked to. However, I don't think it explains the problem that I'm having, because I'm not doing anything (that I'm aware of) under interrupt. Task scheduling, including connecting to AWS, is all done using the system workqueue. The aws_iot library does make use of an event_handler but all that does is print out the event to the log (and I'm using deferred logging). I guess it's possible that there is something in the aws_iot library or the mqtt_helper that's attempting to take a semaphore under interrupt but that seems unlikely as I'm sure other people would have encountered the same problem before me.

Scott

RE: Kernel panic on nRF9151 when connecting to AWS

hmolesworth — Thu, 12 Jun 2025 22:58:14 GMT

Edit: Oops, just noticed you already traced the instruction to assert.c. Maybe the link below will still help.

Try to look up where function is located with arm-none-eabi-addr2line; this (usually) gives the source file and line number:

arm-none-eabi-addr2line -e build-folder/zephyr/zephyr.elf 0x000612d2

For such an interrupt error, this discussion might help:

zephyr-fatal-error-4-kernel-panic-on-cpu-0