nRF9160 modem_shell example code crashes when connecting to CMW500

[bc_metco]

 SDK1.9.1 with example of modem_shell. 

modem fw is up to date, version 1.3.2

the fw crashes as soon as CMW500 trying to establish a connection.

[helsing]

"Stack overflow" is a keyword here. Try using addr2line using LR in order to find out what caused the crash. It looks to be related to something in the time_thread in date_time_core.c.

For 0x41000000/lr, type the following into the command line:

arm-none-eabi-addr2line -e <path to build\zephyr\zephyr.elf> 0x41000000

This will return a the line in the code related to the crash. Looking it up might give you some hints regarding the crash. This line would also be a good start for setting a break point.

[bc_metco]

what's the command line you are referring to? Do you mean the dev kit? No, I got the message from the UART port which is on our customized board build up with nRF9160 chipset. We don't have the resource to hook our customized board and debug it on the fly. I was hoping you, Nordic team, could replicate the error and updated the example code and I can test it from there. 

[helsing]

Hi Bo, sorry for the delay.

bc_metco said:

what's the command line you are referring to?

I am reffering to Command Prompt in Windows. When sitting at a computer with development tools for Nordic installed then: Press the Windows button, type 'cmd' and press enter. Then you cmd.exe (Command Prompt) will open.

Here are the steps for using arm-none-eabi-addr2line:

AHaug said:

Also for errors like this you can do some investigating with arm-none-eabi-addr2line:

1. Check if you have arm-none-eabi-addr2line set up by running "where arm-none-eabi-addr2line" in a cmd window.
   1. This should return something like "C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q3\bin\arm-none-eabi-addr2line.exe"
   2. If it does not return this, then there might be some issues with the gnuarmemb path configuration
2. Next step is to investigate what is in the R15/pc and R14/lr addresses
   1. arm-none-eabi-addr2line -e <path to _build\zephyr\zephyr.elf> <0x000211a8> for r15/pc
   2. arm-none-eabi-addr2line -e <path to _build\zephyr\zephyr.elf> <0x00018b3d> for r14/lr

2. Should give you what function call that causes the kernel panic deep down in the stack. Remember to replace "<path to _build\zephyr\zephyr.elf>" with your actual path

[bc_metco]

When should I run those commands? Should I run the commands after the CMW500 triggered those error? Or I can ran it without CMW500 hooked up? It's a little bit confused to me what needs to be done at here. The screenshot I showed before is from the serial portal that connected to the DUT. but why the windows prompt is trying to prob the fw that built on my local PC? I don't understand that part.

[helsing]

It looks like you are almost there. You can run this command regardless of being connected to CMW500. However, you need to be running the command on a computer with access to the build folder for your application(it looks like you are doing so). The goal is to debug your application as arm-none-eabi-addr2line can be used to find out which part of your application's code was involved when Stack overflow occurred.

Thank you for posting the output from cmd. It is a good start that the computer is able to find arm-none-eabi-addr2line. Next thing, try removing '<' and '>' and insert the address in 'r14/lr' from the image in your initial post: . It will also be interesting to see what is returned when inputting what is in r15/pc:

Please try these two commands and post what is returned:

arm-none-eabi-addr2line -e C:\MTRepos\nordic\myapps\my_modem_shell\build\zephyr\zephyr.elf 0x41000000

arm-none-eabi-addr2line -e C:\MTRepos\nordic\myapps\my_modem_shell\build\zephyr\zephyr.elf 0xaaaaaaaa

[bc_metco]

output result:

[helsing]

Hi Bo, sorry for the delay.

Thank you for sharing the output from addr2line. Unfortunately, the output does not help as much as I was hoping for.

We would like to reproduce the issue:

• Would you be able to share the configuration file for CMW500?
• Which board are you using?
• If you are using the DK, then which hardware revision?
• If you are using a custom board, which revision of the nRF9160 SIP are you using? The SIP should be marked with either 'B0' or B1'.

[helsing]

You could read out your revision by either AT command: AT%HWVERSION or look on the nRF9160 SIP for marking "B1".

"B1" -> Revision 2

"B0" -> Revision 1 

Only revision 2 is supported by modem firmware v1.3.2.

[bc_metco]

Here is the SiP, HW version should be B1. I will upload CMW500 configuration file later.

[helsing]

Thank you for confirming the SIP version. It would be great if you could also comment on the DK HW version. This can be found on the back of the DK there should be a sticker, below 'PCA10090'. The version could be for example '1.0.0'.

Please also let us know if you have tried increasing DATE_TIME_THREAD_STACK_SIZE.