nrf9160 custom board AT client not working

[Tjaz]

Greetings,

we are developing a custom board that holds a nrf9160 chip. We have uart lines out on pins 28 and 29, as on the DK. We need to use the AT client in order to flash certificates to the modem. This used to work and we successfully flashed certificates on some 10 or so devices using this hex: 

91dk_at_client_increased_buf.hex

For some unknown reason, the LTE link monitor could successfully communicate only on some PCs (on others, all AT commands timed out, but only for our boards. Communicating with the DK worked OK).

I tried something similar as suggested here: https://devzone.nordicsemi.com/f/nordic-q-a/58055/nrf9160-custom-board---connect-uart-and-send-at-commands/238646#238646 
and modified both overlay files with our setup (apeended to spm and added a file to at_client):

&uart0 {
	current-speed = <115200>;
	status = "okay";
	tx-pin = <29>;
	rx-pin = <28>;
	rts-pin = <0xFFFFFFFF>;
	cts-pin = <0xFFFFFFFF>;
};

&uart1 {
	status = "okay";
	current-speed = <115200>;
	tx-pin = <27>;
	rx-pin = <26>;
	rts-pin = <0xFFFFFFFF>;
	cts-pin = <0xFFFFFFFF>;
};

&i2c2 {
	status = "okay";
	compatible = "nordic,nrf-twim";
	sda-pin = < 11 >;
	scl-pin = < 12 >;
    clock-frequency = <I2C_BITRATE_FAST>;
};

which, for uart0, is the same as the DK.

I am now wondering what could be the cause of this. I would assume the LTE Link Monitor software works (since it can communicate with the AT client on the dev kit), so there must be some additional configuration required for our board?

Ill be happy with any ideas or suggestions regarding this.

I would also like to add that writing a program that uses at_cmd_write() to send, for example, AT+CFUN?, returns the expected result (+CFUN=1). So the modem works.

- Tjaž

[Didrik Rokhaug]

Hi.

 

 

We need to use the AT client in order to flash certificates to the modem. This used to work and we successfully flashed certificates on some 10 or so devices

 Do you know what is different between then and now?

 

For some unknown reason, the LTE link monitor could successfully communicate only on some PCs (on others, all AT commands timed out, but only for our boards. Communicating with the DK worked OK).

 Does the computer that does not work have something in common?

Is there anything that sepparates them from the computers that does work?

 

all AT commands timed out

 What AT commands did you test?

What does the terminal window say? Did you get a response from the device at all, even though it came "too late for the Link Monitor"?

Are you able to read any application output on the computers that does not work?

Is the behaviour consistent across all your custom devices?

Best regards,

Didrik

[Tjaz]

Do you know what is different between then and now?

Sorry, I was maybe a bit unclear in my first post. As far as I am aware, nothing has changed. But due to the corona-virus and remote-work, I can not 100 % verify the situation.

Does the computer that does not work have something in common?

Is there anything that separates them from the computers that does work?

It works on a specific windows machine, but not on another windows machine and neither on 2 separate Linux machines.

What AT commands did you test?

What does the terminal window say? Did you get a response from the device at all, even though it came "too late for the Link Monitor"?

Are you able to read any application output on the computers that does not work?

Is the behaviour consistent across all your custom devices?

I testes simple commands such as "AT", "AT+CFUN?" and "AT+CFUN=1", ... They all time out and there is no response from the at client at all (not even after a bigger delay, as you suggested). I get application output at the beginning - the booting message and then "The host AT client has started" (or something like that). Flashing some other application, I can also see LOG/printk output.

The behavior was observed on 2 devices. I will be able to check more in the next week, but probably never all of them.

I maybe suspect this has something to do with UART configs -> we use UART0 for outward communication and UART1 for takling to nrf52. Maybe UART0 is blocking the UART0 line? is this possible?

Regards,
Tjaž

[Tjaz]

Hello,

I have since found out, that communicating with the AT client does not work only with some applications (terminals) on my computer. So, it is not the AT client that is at fault, but the software interfacing with it.

That is, I get no responses to AT commands in LTE Link Monitor, and also no responses using minicom. But writing a python script using Serial, I get correct responses from the AT client.

For example, a script like this works:

#!/usr/bin/env python3
import serial
import time

ser = serial.Serial("/dev/ttyUSB0", 115200, timeout=2)  # open serial port
print(ser.name)         # check which port was really used

ser.write(b'AT\r\n')     # write a string
s = ser.readline()        # read line
print(s.decode("ascii"))  # prints OK

time.sleep(1)

ser.write(b'AT+CFUN=4\r\n')
s = ser.readline()
print(s.decode("ascii"))  # prints OK

time.sleep(1)

ser.write(b'AT+CFUN?\r\n')
s = ser.readline()
print(s.decode("ascii"))   # prints +CFUN=4

This now raises the question why LTE Link Monitor works with the nrf9160 DK, and not our custom board (sometimes).

Regards,

Tjaž

[Didrik Rokhaug]

Hi, and sorry for the late reply.

I am happy to hear that you got something working.

 

Tjaz said:

This now raises the question why LTE Link Monitor works with the nrf9160 DK, and not our custom board (sometimes).

 How do you connect your custom device to the computer? Have you ruled that out as a source of your problem?

 

Tjaz said:

That is, I get no responses to AT commands in LTE Link Monitor, and also no responses using minicom.

 Have you tried to see if the AT command reaches the nRF9160? If it does not, that would explain why you do not get a reply. One way you might be able to check is to check the pin/trace used for the UART signals with an oscilloscope or logic analyzer.

Best regards,

Didrik