Can't establish LTE connection with CONFIG_NRF_MODEM_LIB_TRACE_ENABLED turned on.

[ludw]

I have built on the CoAP example a POST request to the server. This works now without any problems.

I do send the received signal power within my POST. To get the power I use the AT command: AT+CESQ

The problem arises after roughly 20 min where the code get stuck in the <at_cmd_write> function. The timer interrupt callbacks still working correctly.

To get a clue what the problem could be, I wanted to do a modem trace. But if I add the configuration : CONFIG_NRF_MODEM_LIB_TRACE_ENABLED=y, the code get stuck already in the modem_configure() function from the example.

What could be the problem, or how can I track down the problem?

I'm using the VS Code extension as my development environment, the SDK Version 1.7.0 and Modem Version 1.3.0.

My config files are:

0216.prj_qemu_x86.conf2335.overlay-carrier.conf

I'm not 100% sure if I configured everything correct that all of these are used for the west build.

Thanks in advance.

[ludw]

I think that is not the problem, because after the software on the NRF9160DK crashes on the line with the AT command (CPU goes to IDLE state) I still receive timer event notifications over UART in the LTE Link Monitor.

I think the modem does not response for some reason and because I use a blocking AT command, my software waits for the response forever.

Thank you for your help.

[Håkon Alseth]

Hi,

 

Could you elaborate on what crashes? Do you have a log?

Have you tried to enter debug mode to see where the device is stuck?

 

Kind regards,

Håkon

[ludw]

Maybe I miss formulated it a bit wrong. It is not directly a crash. The main thread with my code gets stuck in the idle function (https://github.com/zephyrproject-rtos/zephyr/blob/71c0cebac9049ef2ce5ea377681ac8140a341598/kernel/idle.c#L64).

If I have these lines included in the code, the code stops at the at_cmd_write() function. The "Before AT" gets printed and the "After AT" not. Other printk values from other threads are still displayed.

If I exclude these lines, the code works without problems.

static const char get_signal_power_command[] = "AT+CESQ";
enum at_cmd_state state;
char temp[50];

printk("Before AT\n");
at_cmd_write(get_signal_power_command, temp, sizeof(temp), &state);
printk("After AT\n");

Everything works fine after the startup, but after roughly 20 min the code gets stuck.

I think the main thread waits for a response from the at_cmd_write function.

I published my example project on GitHub. This is the line that creates the problem:

https://github.com/ludwisc/NB_IOT_AT_CRASH/blob/602b27bb26ff4fa1c59198ed78164692517340fe/src/lte_communication.c#L132

Thank you for your help.

[Håkon Alseth]

Hi,

 

When you are manually starting up the modem in the application space, you also need to setup the at_cmd library, like done here:

https://github.com/nrfconnect/sdk-nrf/blob/v1.7.0/samples/nrf9160/https_client/src/main.c#L50

 

Can you try this and see if it works better?

 

Kind regards,

Håkon

[ludw]

Thank you for your reply.

Unfortunately, there was no change when I added the setup function.

I was able to narrow down the problem further. The at command is most likely not the cause of the problem. It's only a symptom of the main problem.

The problem is somewhere in the coap send function.

If I comment this line out: https://github.com/ludwisc/NB_IOT_AT_CRASH/blob/6b1a57cf27078739aa985686f738301a7ded8f24/src/lte_communication.c#L273
the code works without crashing but of course sends nothing to the cloud.

The really strange part about this is, that if the send line is in the code, the software crashes always after exactly 18 send function executions.

If the at command in the code (https://github.com/ludwisc/NB_IOT_AT_CRASH/blob/6b1a57cf27078739aa985686f738301a7ded8f24/src/fsm.c#L60)
is commented out, the software continuos to run after the 18 sent packages and continuos to send data packages to the server. If I want to send an at command via the Link Monitor after the 18 packages, it doesn't work, and I receive a time-out Error. Before 18 packages are sent, the at commands in the Link Monitor work as expected.

Kind regards