Modem 30 minute lockup

This is driving me totally nuts. There are inconsistent pieces of information in documents and code. I am getting a modem reset loop problem. The documentation says the timer does not run when the modem has no power. That tells me I have to leave power on in order to get out of this ridiculous mess that cuts me off from any and all LTE-M and NB-IoT networks. The message from some asset tracker code tells me I can get out by doing a power reset, but that does not work.

How in blazes do I get out of this fricking mess????? This is at least one day down the drain.

How about 5 minutes rather than 30 minutes. How about something that simply restores the modem?

Did I put a bug into the code? I can't imagine how, although I do put in printfs.

Thanks.

Burt S.

  • I eventually was able to get out of the mess. It began when I tried adding this to asset_tracker_v2 prj.conf

    CONFIG_LWM2M_CARRIER_PDN_IPV4=y
    CONFIG_LWM2M_CARRIER=y
    CONFIG_LWM2M_CARRIER_SETTINGS=y
    CONFIG_LWM2M_CARRIER_CUSTOM_APN="iot.nb"

    in an attempt to do the equivalent of

    AT+CGDCONT=1,"IP","iot.nb"

    as indicated by the clowns at https://www.twilio.com/docs/iot/wireless/network-configuration#how-do-i-set-the-apn-with-at-commands. Not only did I lock up the modem but I wasn't configuring any "iot-nb" because I don't know how to set auto_startup to 1 in lwm2m_settings.c. It involves a modem key but I have no idea how to create a simple modem key appropriate for the purpose. It seems like this is another complicated topic involving security knowledge. Please help.

    I also tried setting

    CONFIG_PDN_DEFAULTS_OVERRIDE=y
    CONFIG_PDN_DEFAULT_APN="iot.nb"
    CONFIG_PDN_DEFAULT_FAM_IPV4=y
    CONFIG_PDN_LOG_LEVEL_DBG=y
    CONFIG_NVS=y
    CONFIG_MODEM_KEY_MGMT=y
    CONFIG_SMS=y

    and although that did not break anything, it did not solve the problem whereby Twilio SIMs will not connect to T-Mobile. Can you tell me why they cannot just keep things simple like Soracom and the rest of the world?

    I guess you have people who know all the tricks and I hope you can help me get back on my feet again. Thanks. Oh, yeah,

    Burt

  • I guess I misread that Twilio web page. I thought they were telling me that I needed to configure the APN somewhere in order to connect/register to the network; like I had to copy the APN that the SIM uses to somewhere else in order to establish an NB-IoT connection. Anyway, I have a ticket open with KORE Wireless/Twilio and they opened a secondary ticket with T-Mobile. I don't think those KORE Wireless folks have any clue about the company Twilio that they purchased; not on a technology level, at least.

  • Now I am not sure of anything. It seems that I now have killed a perfectly good Soracom SIM card by inserting a line of code into lte_lc_func_mode_set() [just a convenient place]

    err = nrf_modem_at_printf("AT+CGDCONT=%u,%s,%s", 0, "IP", "soracom.io");
    if (err) printf("setting CGDCONT returns %d in %s\n", err, __func__);

    The SIM will no longer connect. If I use a good SIM I connect and the command

    AT+CGDCONT?

    returns

    DCONT: 0,"IP","soracom.io","10.164.75.168",0,0

    after connecting. The bad SIM (that was a good SIM before experimenting with AT+CDGCONT) returns

    +CGDCONT: 0,"IP","soracom.io","",0,0

    How did this mess occur and how do I fix it?

    Thanks,

    Burt

  • Okay, I figured out how to fix the Soracom SIM problem: AT%XFACTORYRESET=1 after AT+CFUN=0. That got rid of whatever hidden garbage I had inadvertently added.

    And that helped me further confirm that the Twilio and T-Mobile present Narrowband SIM is a mess.

    I changed the CGDCONT code above to

    err = nrf_modem_at_printf("AT+CGDCONT=%u,%s,%s", 1, "IP", "iot.nb");
    err = nrf_modem_at_printf("AT+CGDCONT=%u,%s,%s", 2, "IP", "wireless.twilio.com");
    err = nrf_modem_at_printf("AT+CGDCONT=%u,%s,%s", 3, "IP", "super");

    which seems to not hurt anything but it does not solve that Twilio/T-Mobile/NB problem.

    Burt

  • Hello Burt, 

    Burt said:
    but it does not solve that Twilio/T-Mobile/NB problem.

    I will need to see the modem traces in order to see what is going on inside the device. Do you get any error messages in your application logs? 

    Thanks!

    Kind regards,

    Øyvind

Related