Crash application after LTE CELL found

Hi,

The version of modem is 1.3.5 and NCS 2.2.0.
The hardware is a custom board.

When the application is running, the reset occurs after MODEM_EVT_CELL_UPDATE.

It's very strange because, I have a pre-prod of 50 x devices and it's concerning someones of them.

I tested udp application provided by the SDK and I have the same issue.

And I don't think it's a power supply issue because I checked voltage during running application and there is no leak.

For finish, I read Case ID: 309798 from devzone and I think it's probebly the same issue.

Do you have an idea ?

Thanks

Parents
  • Hello, 

    For finish, I read Case ID: 309798 from devzone and I think it's probebly the same issue.

    Did you do as my colleague suggested in this ticket? I.e. add CONFIG_RESET_ON_FATAL_ERROR=n and CONFIG_THREAD_NAME=y to your prj.conf. You could also try adding CONFIG_ASSERT=y. More logs are needed in order to find the root cause of this issue.

    When the application is running, the reset occurs after MODEM_EVT_CELL_UPDATE.

    What makes you think it is related to modem_evt_cell_update? There are sensors enabled after this. To me it seems more of an issue with one of these. 

    The hardware is a custom board.

    Did you have a design review of your board? Have you ensured all components are soldered correctly? 

    Kind regards,
    Øyvind

  • Hi,

    thanks for your reply.

    I tried to use "udp" application and I added   CONFIG_RESET_ON_FATAL_ERROR=n, CONFIG_THREAD_NAME=y, CONFIG_ASSERT=y in prj.conf.

    You can see below the result :

    When the device find a new cell, it reboot !

    What makes you think it is related to modem_evt_cell_update? There are sensors enabled after this. To me it seems more of an issue with one of these. 

    No, sensors are enabled right after reset. There is some messages from drivers written before the message "Booting Zephyr OS build".

    Did you have a design review of your board? Have you ensured all components are soldered correctly? 

    No, I didn't ask to make a review of my board and I would like to do it ! Yes I think I have no problem of compoments poorly soldered.

Reply
  • Hi,

    thanks for your reply.

    I tried to use "udp" application and I added   CONFIG_RESET_ON_FATAL_ERROR=n, CONFIG_THREAD_NAME=y, CONFIG_ASSERT=y in prj.conf.

    You can see below the result :

    When the device find a new cell, it reboot !

    What makes you think it is related to modem_evt_cell_update? There are sensors enabled after this. To me it seems more of an issue with one of these. 

    No, sensors are enabled right after reset. There is some messages from drivers written before the message "Booting Zephyr OS build".

    Did you have a design review of your board? Have you ensured all components are soldered correctly? 

    No, I didn't ask to make a review of my board and I would like to do it ! Yes I think I have no problem of compoments poorly soldered.

Children
  • Hello, 

    SP said:
    No, I didn't ask to make a review of my board and I would like to do it ! Yes I think I have no problem of compoments poorly soldered.

    Our HW people can help reviewing your design, just register a new DevZone ticket and ask for a HW review Slight smile

    SP said:
    When the device find a new cell, it reboot !

    Very strange behavior. Could you please collect a modem trace from the device when the issue occurs? That said, do you have e.g. a nRF9160 DK to test with as well? 

    SP said:
    I tried to use "udp" application and I added   CONFIG_RESET_ON_FATAL_ERROR=n, CONFIG_THREAD_NAME=y, CONFIG_ASSERT=y in prj.conf.

    Is this the only configurations you have done to the UDP sample? 

    Kind regards,
    Øyvind

  • Hi,

    Very strange behavior. Could you please collect a modem trace from the device when the issue occurs? That said, do you have e.g. a nRF9160 DK to test with as well? 

    Yes I have already make a trace modem before I wrote the ticket:
    trace-2023-10-16T05-36-43.524Z.mtrace

    Here is the trace of my application not UDP sample. But it's the same issue.

    I tried to read this trace but I found nothing !

    That said, do you have e.g. a nRF9160 DK to test with as well?

    I think I will have no issue with nRF9160 DK. The issue is specific to my custom board.
    In addition, I received a pre-serie of 50 x devices from my provider and I have 2 x devices with this issue / 10 x prepared !

    Our HW people can help reviewing your design, just register a new DevZone ticket and ask for a HW review Slight smile

    Yes I'm going to make the ticket.

    Is this the only configurations you have done to the UDP sample? 

    Yes in addition to the other parameters.

Related