9160/LTE; no return from lte_lc_connect() and keeps resetting

[bluebeam]

Hi,

I'm having trouble with my custom 9160 board. It won't connect to LTE-M network and keeps resetting.

My prototype was developed using the 9160DK. I can connect to LTE-M network and send data to nrf Cloud. The combination is 9160 B1A, mfw 1.3.1, and NCS SDK1.7.1.

Now my custom board is using B0A silicon, with mfw 1.1.1. I have upgrade/downgrade between 1.1.1 and 1.3.1 multiple times. But that doesn't seem to make any difference.

My test code is simplified to like this:

LOG_INF("modem init");

lte_lc_register_handler(lte_lc_evt_handler);

err = lte_lc_init();

LOG_DBG("lte_lc_init(): %d", err);

err = lte_lc_connect();

LOG_DBG("lte_lc_connect(): %d", err);

LOG_INF("modem init done");

The log message looks like this:

00> I: modem init

00> D: Sending AT command to set system mode: AT%XSYSTEMMODE=1,0,1,0

00> D: System mode (4) and preference (0) configured

00> D: lte_lc_init(): 0

00> D: Sending AT command to set system mode: AT%XSYSTEMMODE=1,0,1,0

So it went through lte_lc_init(), but never returned from lte_lc_connect(). It will stays there for various amount of time, from a few seconds to a minute or so, then it resets.

Since this is a custom board, I try to figure out if any hardware issue could cause such problem. I assume lte_lc_connect() will search for the network and try to make a connection. The document says it has a timeout. I assume if it timed out, it should return from lte_lc_connect() with an error code? But it never returned and always resets after a while. Any possible explaination lte_lc_connect() could cause this? Or should I more look at hardware side? How can I get more debug information to troubleshoot this? I already set CONFIG_LTE_LINK_CONTROL_LOG_LEVEL_DBG=y.

The same code runs fine on the 9160DK and get connected in a few seconds.

Thanks!

[Charlie]

Hi Bluebeam,

Here you can find a udp sample project with a custom board named bluebeam91_nrf9160(thingy91 copy).

I can build it under NCS v1.5.2 environment without issue.

ncs152_udp.zip

Best regards,

Charlie

[bluebeam]

Hi Charlie

Thanks for the sample project. Yes it does compile file. That's very helpful. I realize the device tree file is somewhat different in 1.5.2 than in 1.7.1. So I went back to make a copy of the 1.5.2 version of nrf9160dk_nrf9160 board file and made all the changes I think is necessary. I got rid of the nrf52840 since my custom board only has a single nrf9160. I think it does work a lot better this time but it still failed at the probably the last step. It complains the image can't fit in the FLASH region. As you can see the error below. Somehow the FLASH is overflowed by 16KB. So I must missed something in the device configuration. But I can't find what it is. This is nothing to do with how large my app is. I can comment out all the app code and it still does the same.

I'm attaching the complete board files here. If you could take a look to see what went wrong I really appreciate it. Thanks!bluebeam91_nrf9160.zip

=======================================================================

/home/chrisz/zephyr-sdk-0.15.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld: zephyr/zephyr_prebuilt.elf section `.gnu.sgstubs' will not fit in region `FLASH'
/home/chrisz/zephyr-sdk-0.15.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld: SPM and app are sharing an SPU region. Cannot partition flash correctly into secure and non-secure. Adjust partitions sizes so they are placed in separate regions.
/home/chrisz/zephyr-sdk-0.15.1/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.1.0/../../../../arm-zephyr-eabi/bin/ld: region `FLASH' overflowed by 16384 bytes
Memory region         Used Size  Region Size  %age Used
           FLASH:         64 KB        48 KB    133.33%
            SRAM:        8768 B        64 KB     13.38%
        IDT_LIST:          88 B         2 KB      4.30%
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.