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.

[Håkon Alseth]

Hi,

 

Could it be that you're seeing this restriction?

https://infocenter.nordicsemi.com/topic/nwp_042/WP/nwp_042/intro.html?cp=2_0_7_0

 

If that is the case, a power-cycle would fix the problem.

 

Kind regards,

Håkon

[ludw]

In the meantime I commented out the line with the AT command. The software now works without crashing for multiple hours. After about roughly 20 min, I sent an AT command via the LTE Link Monitor to test whether the AT commands work and received a timeout response. Right after a reset of the board, the AT commands works properly and I receive a response.

The board is still sending the data over LTE, while the AT commands are not working. I know that the data is being sent, because I receive them on the server.

If I understand you correctly, the data would not be sent if the modem is in a loop restriction.

Thank you for your help.

[Håkon Alseth]

Hi,

 

ludw said:

In the meantime I commented out the line with the AT command. The software now works without crashing for multiple hours. After about roughly 20 min, I sent an AT command via the LTE Link Monitor to test whether the AT commands work and received a timeout response. Right after a reset of the board, the AT commands works properly and I receive a response.

A timed out response in LTE Link Monitor can very well be the uart connection between your computer and the kit. Try resetting the PC application (CTRL+R) and reselecting the device in the drop down menu.

 

Kind regards,

Håkon

[ludw]

The LTE Link Monitor is working correctly. I reset the Monitor and the problem still exists. In addition, I receive the printk() outputs.

[Håkon Alseth]

Hi,

 

It sounds like the UART RX is disabled after some time, possibly due to a framing error or similar (ie. noise on the line).

As a test, could you try to comment out this line and see if the issue still exists? https://github.com/nrfconnect/sdk-zephyr/blob/v2.6.99-ncs1/drivers/serial/uart_nrfx_uarte.c#L1038

 

Kind regards,

Håkon

[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

[Håkon Alseth]

Hi,

 

You are continuously sending, and not handling the receiver part. You are effectively running out of space, thus the whole application halts.

See the coap_client sample on how to setup the rest of the coap protocol:

https://github.com/nrfconnect/sdk-nrf/tree/main/samples/nrf9160/coap_client

 

Kind regards,

Håkon