Unable to initialize modem/at commands

[brad_57]

I’m working on code for a custom board which has an nRF9160 SIAA B1 version. I have a couple earlier boards which use the nRF9160 SICA B0 version. On the older boards, I have been able to initialize the modem, connect to the LTE network, and send/receive data. I'm using the same SIM card on all boards, which works on both the older boards, so it should not be the problem. All boards have modem firmware 1.3.1, and the ones that are able to initialize the modem are using nrf connect sdk version 1.7.1.

On the new board, I've stepped back from trying to run my code, and I'm now trying to get at_client sample to run successfully using either v1.7.1 or v1.8.0, however I get the following error when initializing the at commands:

[00:02:30.836,395] <err> at_cmd: Failed to open AT socket (err:-117)

Additionally, the printk statement in the sample somehow causes incomprehensible garbage to be put into terminal, despite having the correct settings in the dts file (based on printing that comes through properly immediately before, and on my experience with the other boards):

Looking up the code, err 117 is EHOSTDOWN, and I’m having trouble making sense of that. Using a debugger and following the init sequence, I can see it fail on a system call to create the socket for a UDP connection between the main processor and modem. I'm confused as to what this error could indicate is going wrong, as I thought this is communication from one part of the chip to another, so if the rest of the system is running properly (as far as I can tell), the modem must be powered on too. This is perhaps a bad assumption to make, however I can't see anything visibly wrong on the board, and, for the time being, I only have one working board with the nrf9160 siaa b1.

I have also tried both sdk versions 1.9.0 and 1.9.1, with the appropriate adjustments to my code for initializing: nrf_modem_lib_init(NORMAL_MODE) in place of at_cmd_init, and nrf_modem_at_cmd in place of at_cmd_write. I seem to get a timeout error (116 ETIMEDOUT), which I was able to chase to the RPC init sequence using a debugger. That lead me through some assembly, and I wasn't able to understand exactly what it was timing out on. When I tried running those versions of the sdk again today, the system would not print the debug logging messages to terminal, so I don't have the exact output for that unfortunately. When I try running the at_client sample, I get the same output as pictured above, minus the logs.

Based on that and the mfw/sdk compatibility matrix, I chose to keep trying with v1.8.0 instead of v1.9.x.

These are the options in my prj.conf file (again, using sdk v1.8.0):

CONFIG_HEAP_MEM_POOL_SIZE=16384

CONFIG_MAIN_STACK_SIZE=8192

CONFIG_NRF_MODEM_LIB=y

CONFIG_AT_HOST_LIBRARY=y

CONFIG_UART_INTERRUPT_DRIVEN=y

CONFIG_UART_ASYNC_API=y

CONFIG_NETWORKING=y

CONFIG_NET_NATIVE=n

CONFIG_NET_SOCKETS=y

CONFIG_NET_SOCKETS_OFFLOAD=y

CONFIG_NET_SOCKETS_POSIX_NAMES=y

CONFIG_MODEM_INFO=y

CONFIG_MODEM_KEY_MGMT=y

CONFIG_LTE_LINK_CONTROL=y

CONFIG_LTE_NETWORK_MODE_LTE_M=y

CONFIG_LTE_AUTO_INIT_AND_CONNECT=n

CONFIG_BOOTLOADER_MCUBOOT=y

CONFIG_NEWLIB_LIBC=y

CONFIG_DEBUG_OPTIMIZATIONS=y

CONFIG_DEBUG_THREAD_INFO=y

CONFIG_LOG=y

CONFIG_LOG_DEFAULT_LEVEL=4

CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_DEBUG_COREDUMP=y

CONFIG_DEBUG_COREDUMP_BACKEND_LOGGING=y

Might be worth noting that I've tried commenting out the options not included in at_client's prj.conf (besides logging), but it made no difference.

What could be causing the modem init to fail? Are there any other methods I can try to get more information? Perhaps I have missed something important in configuration for this specific type and version of the chip? I was not able to find anything like that on my own. I would appreciate any insight or direction.

Thank you for taking the time to read this,

Brad

[Håkon Alseth]

Hi,

 

I only have one working board with the nrf9160 siaa b1.

How many devices are showing the initial problem?

Could you try to reprogram the problematic devices with mfw v1.3.1, and see if this changes the behavior in any way?

 

What could be causing the modem init to fail?

It can be any number of things, but the usual scenario is if the modem fw is not of a newer version.

 

Kind regards,

Håkon

[brad_57]

Hi Håkon,

Just the one is showing this issue. I have another one that the programming app won't detect, and I suspect there's a bad solder joint on it. I'll be able to test more with an electrical engineer next week. Worst case scenario, we should be able to determine if this is the issue with both boards next week.

I've re-downloaded mfw v1.3.1 and programmed it onto the nrf, but am seeing the same results.

Do you know if there's anything else worth trying/looking into in the meantime?

Thank you,

Brad

[Håkon Alseth]

Hi Brad,

 

Have you gotten the layout reviewed by us?

When going from revision 1 to revision 2, there are a couple of things that needs to be handled, as per this informational notice:

https://infocenter.nordicsemi.com/pdf/pcn_134_v1.0.1.pdf?cp=2_0_2_3

A very crucial change is this:

"SiP external cap, DEC0, to be changed from 47uF to 4.7uF"

 

Kind regards,

Håkon

[brad_57]

Hey Håkon,

We haven't had our layout reviewed by you guys yet. I mentioned it to the team, and we're considering opening a private support ticket for it, as we wish to keep the design confidential. Is there a basic NDA we could enter (or something similar) to ensure it stays confidential?

I shared that PDF with the electrical engineer to make sure the layout is consistent with it. Looking at the schematic, we do spec a 4.7uF cap for DEC0. The actual cap on my board may be 10uF though.

Thank you again,

Brad

[Håkon Alseth]

Hi Brad,

 

I would recommend that you open a private ticket and request for review of the design, just in case.

If you need a NDA to be in place, this should be done through our sales department. If you do nto have the contact details of your local sales manager, please send me a direct message with your location and I'll provide his/her's contact details.

 

Kind regards,

Håkon