NRF9160: Downloading FOTA image crashes with SDK 1.4

RE: NRF9160: Downloading FOTA image crashes with SDK 1.4

Simon — Tue, 08 Dec 2020 17:15:23 GMT

Could you try setting CONFIG_LOG=y in prj.conf? I did some experiments with a hello world sample and figured out that has to be done in order to get these log printed out:

Then you should get the faulting instruction address that caused the error, and you can look at the file <..>/build/zephyr/zephyr.lst to figure out what function caused this error. You can also use arm-none-eabi-addr2line.exe like done in this ticket.

If you can't find it, I would just recommend you to add a bunch of logs (using printk()) everywhere in your program to locate where the hardfault occurs.

To be honest, I have not handled too many cases regarding hardfaults so there may be better ways of going about this. However, using logs always works for me when trying to locate the last line that was executed before a crash occurs.

Best regards,

Simon

RE: NRF9160: Downloading FOTA image crashes with SDK 1.4

fastfox — Thu, 03 Dec 2020 11:20:36 GMT

Oh crap, I've messed up some versions in git. The error above happens because I forgot the workaround from my fork for setting the timeout to TLS socket bug described in here https://devzone.nordicsemi.com/f/nordic-q-a/68594/nrf9160-download_client-does-not-work-anymore-in-sdk-1-4

Anyway. The crash hunt continues...

RE: NRF9160: Downloading FOTA image crashes with SDK 1.4

fastfox — Thu, 03 Dec 2020 10:05:43 GMT

Hi,

No luck with finding the line yet. but I found another bug. This a a bit more straight forward. download_client goes haywire and interprets HTTP headers as payload. See attached log, I commented my analysis to there. Consider this as issue/bug report/what_ever to download_client.

I think the ultimate fault is that download_client does not use the length fields in HTTP header to decide the lenght of the payload in hand. Let me know your view

I hit this 90% of times when I try to reproduce the crash problem.

devzone.nordicsemi.com/.../download_5F00_fails_5F00_commented.log

RE: NRF9160: Downloading FOTA image crashes with SDK 1.4

Simon — Wed, 02 Dec 2020 09:49:18 GMT

Are you able to locate the exact line that causes the program to crash? Try to enable more logging by setting these in prj.conf:

CONFIG_DFU_TARGET_LOG_LEVEL_DBG=y
CONFIG_DOWNLOAD_CLIENT_LOG_LEVEL_DBG=y
CONFIG_FOTA_DOWNLOAD_LOG_LEVEL_DBG=y

The value of the link register is not faulty. Usally it is used to hold the value of the address you'll return to after a jump. This is not the case for exceptions, ffffffa0 is an exception return value that says something about what context (interrupt, what stack etc..). Check out this: https://developer.arm.com/documentation/100235/0004/the-cortex-m33-processor/exception-model/exception-entry-and-return

Best regards,

Simon

RE: NRF9160: Downloading FOTA image crashes with SDK 1.4

fastfox — Wed, 02 Dec 2020 08:31:07 GMT

Hi,

I should have mentioned, it is already at max 4096

RE: NRF9160: Downloading FOTA image crashes with SDK 1.4

Jon Helge — Wed, 02 Dec 2020 08:14:26 GMT

A wild shot, but could you try to increase CONFIG_DOWNLOAD_CLIENT_STACK_SIZE ?