• State Verified Answer
  • Replies 3 replies
  • Subscribers 88 subscribers
  • Views 677 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 262437
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

App Crash if modem commands are issues on the main thread

Nikola Markovic

I think that the related ticket to the problem that we have observed is:

https://devzone.nordicsemi.com/f/nordic-q-a/60850/nrf9160-secure-services-causing-a-crash

I have seen some info where this crash is being investigated, but I am not sure if solution exists in SDK 1.4.1. I see a workaround and I have not tried it as it seems to require changes to SPM, which I'm not familiar with.

If this is the same issue, we are reporting what we have observed...

Our original application would would make use of following AT commands:

  • Obtain time from modem with AT+CCLK?
  • Obtain modem IMEI with AT+CGSN=1

On button press, the app would make some https calls and establish an MQTT link to azure. After some time or on another button press, the application would disconnect MQTT and LTE. Another button press would repeat the cycle. The cycle would include obtaining modem time with  AT+CCLK? right after LTE link would be obtained. Application has no (k)threads.

The problem is that on a third cycle or so, the application would crash typically on HTTP requests or rarely during MQTT startup.

The application has a generous stack and heap allocation of 8K each. We have also tried tweaking various stack sizes and Kconfig settings per some posts that we have seen on the forums, but none of those seemed to help. The same behavior existed in SDK 1.3.0, 1.3.1 and 1.4.0.

We have since modified our code to make use of date_time and modem_info libraries provided by Nordic and the problem completely disappeared and the application is stable now.

I have posted this ticket in hopes that it would help reproduce and resolve this issue and in hopes that someone can review and determine whether this is the same problem and whether the same workaround applies.

Parents
  • 0

    Hi Håkon,

    I've seen that thread and as I mentioned earlier, I didn't understand how spm_config in Kconfig has effect on the project as it is separate from the main application Kconfig, if something had to be programmed separately, so I didn't pursue that route.

    But say, it spm stack size that needed to be adjusted, how come it was enough for the library calls (which in effect do the same thing) rather than direct nrf_socket(AF_LTE) + nrf_send from main thread. The actual string that I Was sending was a const like "AT+CCLK?\r" (just \r, right?) Those calls perhaps did something different that didn't trigger the crash. I did my due diligence to ensure that I had enough command buffers on my end. 

    I could never get a stack trace/printout because USB was late in connecting. It would be a hard fault and some registers would point to areas around AT command handler and possibly "spm". I think it was a "secure hard fault"  or something like that. The crash would happen inside https socket send(fd),.or was it recv()... I believe, and it would crash as I would try to step over into the native socket function that I had no source for.

    Sorry, this is as much as I have to offer on this issue probably. I'm thinking that the way to reproduce might be to run the https sample in a loop, but add nrf_socket send/receive AT+CCLK into the mix. I may not have the bandwidth to go back and try reproduce this, so feel free to close out this issue if the information is not useful.

    Thanks,

    Nik

Reply
  • 0

    Hi Håkon,

    I've seen that thread and as I mentioned earlier, I didn't understand how spm_config in Kconfig has effect on the project as it is separate from the main application Kconfig, if something had to be programmed separately, so I didn't pursue that route.

    But say, it spm stack size that needed to be adjusted, how come it was enough for the library calls (which in effect do the same thing) rather than direct nrf_socket(AF_LTE) + nrf_send from main thread. The actual string that I Was sending was a const like "AT+CCLK?\r" (just \r, right?) Those calls perhaps did something different that didn't trigger the crash. I did my due diligence to ensure that I had enough command buffers on my end. 

    I could never get a stack trace/printout because USB was late in connecting. It would be a hard fault and some registers would point to areas around AT command handler and possibly "spm". I think it was a "secure hard fault"  or something like that. The crash would happen inside https socket send(fd),.or was it recv()... I believe, and it would crash as I would try to step over into the native socket function that I had no source for.

    Sorry, this is as much as I have to offer on this issue probably. I'm thinking that the way to reproduce might be to run the https sample in a loop, but add nrf_socket send/receive AT+CCLK into the mix. I may not have the bandwidth to go back and try reproduce this, so feel free to close out this issue if the information is not useful.

    Thanks,

    Nik

Children
  • +1 in reply to Nikola Markovic

    Hi Nik,

     

    Nikola Markovic said:
    I've seen that thread and as I mentioned earlier, I didn't understand how spm_config in Kconfig has effect on the project as it is separate from the main application Kconfig, if something had to be programmed separately, so I didn't pursue that route.

    MQTT fetches a random number and uses that as a part of the meta-data sent to the broker, in the data_publish() function. This will be a non-secure callable function to the secure region.

      

    Nikola Markovic said:

    But say, it spm stack size that needed to be adjusted, how come it was enough for the library calls (which in effect do the same thing) rather than direct nrf_socket(AF_LTE) + nrf_send from main thread. The actual string that I Was sending was a const like "AT+CCLK?\r" (just \r, right?) Those calls perhaps did something different that didn't trigger the crash. I did my due diligence to ensure that I had enough command buffers on my end. 

    I could never get a stack trace/printout because USB was late in connecting. It would be a hard fault and some registers would point to areas around AT command handler and possibly "spm". I think it was a "secure hard fault"  or something like that. The crash would happen inside https socket send(fd),.or was it recv()... I believe, and it would crash as I would try to step over into the native socket function that I had no source for.

    Sorry, this is as much as I have to offer on this issue probably. I'm thinking that the way to reproduce might be to run the https sample in a loop, but add nrf_socket send/receive AT+CCLK into the mix. I may not have the bandwidth to go back and try reproduce this, so feel free to close out this issue if the information is not useful.

     My apologies, but without debug information, it is very hard to say what went wrong in this scenario.

    Kind regards,

    Håkon

Related