Custom PCB nRF9160 Link monitor ports

[Yano]

Hi, We have a custom design using an nRF9160.

We can connect and program the device using a jLink though the debug port.

How can we connect the LTE link monitor to the board to transfer AT commands?

Currently our PCB only has access to P0.18 and P0.19 for debug (this can be modified in the next PCB revision).

Can these be re-programmed or are they part of the soft device?

Thanks

[Yano]

Hi Hakon,

I think your getting a bit confused by the issues, just to clarify...

I am using our custom PCB with the at_client application installed.

The application starts and outputs: 

*** Booting Zephyr OS build v2.4.99-ncs1 ***
The AT host sample started

I am using another terminal, not LTE link monitor and AT commands are getting to the nRF

The problem is the nRF is not responding to AT commands.

I have modified: nrf9160_nrf9160ns.overlay, CMakeLists.txt, spm.conf and nrf9160_nrf9160.overlay in /nrf/samples/spm

Please see attached, also attached is our project.

Thanks

Ian

at_client (2).zip

0066.nrf9160dk_nrf9160.overlay

Fullscreen 7457.CMakeLists.txt Download

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

cmake_minimum_required(VERSION 3.13.1)

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/spm.conf")
  set(spm_CONF_FILE
    prj.conf
    ${CMAKE_CURRENT_LIST_DIR}/spm.conf
  )
endif()

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
  set(mcuboot_CONF_FILE
    prj.conf
    ${CMAKE_CURRENT_LIST_DIR}/mcuboot.conf
  )
endif()

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/${BOARD}.overlay")
  set(mcuboot_DTC_OVERLAY_FILE "${CMAKE_CURRENT_SOURCE_DIR}/${BOARD}.overlay")
  set(spm_DTC_OVERLAY_FILE "${CMAKE_CURRENT_SOURCE_DIR}/${BOARD}.overlay")
endif()

find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
project(NONE)

# NORDIC SDK APP START
target_sources(app PRIVATE src/main.c)
# NORDIC SDK APP END

spm.conf7652.nrf9160dk_nrf9160ns.overlay

[Håkon Alseth]

Hi Ian,

 

My apologies for misunderstanding.

Yano said:

I think your getting a bit confused by the issues, just to clarify...

I am using our custom PCB with the at_client application installed.

The application starts and outputs: 

*** Booting Zephyr OS build v2.4.99-ncs1 ***
The AT host sample started

I am using another terminal, not LTE link monitor and AT commands are getting to the nRF

The problem is the nRF is not responding to AT commands.

I have modified: nrf9160_nrf9160ns.overlay, CMakeLists.txt, spm.conf and nrf9160_nrf9160.overlay in /nrf/samples/spm

Please see attached, also attached is our project.

I tested at_client (2).zip, with the merged.hex located in the build-folder (ie. the same .hex as you're currently using).

I can confirm that I am able to get an output on P0.19 (TXD seen from nRF) and I am also able to send AT commands via a terminal on GPIO P0.18 (RXD, seen from nRF)

I tested this by manually connecting P0.19/P0.18 to the nRF9160-DKs SEGGER ICs host UART pins.

Here's my output from when issuing "AT+CLAC" to list all available AT commands (no echo in the terminal):

*** Booting Zephyr OS build v2.4.99-ncs1  ***
The AT host sample started
AT+CFUN
AT+COPS
AT%COPS
AT+CGDCONT
AT+CGACT
AT+CEMODE
AT+CGATT
AT+CGEQOSRDP
AT+CPINR
AT+CPIN
AT+CPSMS
AT+CEDRXS
AT%XPTW
AT+CEDRXRDP
AT+CEREG
AT%XNEWCID
AT%XGETPDNID
AT+CLAC
AT+CMEE
AT+CGMI
AT+CGMM
AT+CGMR
AT+CGSN
AT+CIMI
AT+CSCON
AT+CMGS
AT+CNMA
AT+CNMI
AT+CMGF
AT+CPMS
AT+CGSMS
AT%XSMMA
AT%CMNG
AT+CNEC
AT+CGEREP
AT%CESQ
AT%XPCO
AT+CESQ
AT%XSIM
AT%XBANDLOCK
AT+CGPIAF
AT+CPAS
AT+COPN
AT+CSQ
AT+CEER
AT+CNUM
AT+CRSM
AT+CIND
AT+CLCK
AT+CPWD
AT%XCBAND
AT+CGPADDR
AT+CGCONTRDP
AT%NBRGRSRP
AT+CSIM
AT%XOPNAME
AT%XTIME
AT%XRAI
AT%XCONNSTAT
AT+CEPPI
AT%XDATAPRFL
AT%XMAGPIO
AT%XANTDETMAGPIO
AT%XMIPIRFFEDEV
AT%XMIPIRFFECTRL
AT%XCOEX0
AT%XANTCFG
AT%XEMPR
AT%XSUDO
AT%XPMNG
AT%XRFTEST
AT%XAPNCLASS
AT%XTEMPHIGHLVL
AT%XTEMP
AT%XPRODDONE
AT%XMODEMTRACE
AT%XEPCO
AT%XVBATLOWLVL
AT%XVBATLVL
AT%XVBAT
AT+CCLK
AT%CCLK
AT%XIPV6FAIL
AT%XUSIMLCK
AT%XOPERID
AT%XSMSFALLBACK
AT%XSYSTEMMODE
AT%XSNRSQ
AT+CGAUTH
AT%XMONITOR
AT%SHORTSWVER
AT%HWVERSION
AT%XMODEMUUID
AT%XICCID
AT+ODISNTF
AT+ODIS
AT%ODIS
AT%XNETTIME
AT%XDEEPSEARCH
AT%XFILEWRITE
AT+CEINFO
AT%XPDNCFG
AT+CSODCP
AT%XDATASTOP
AT%XAPNSTATUS
AT%XPOFWARN
OK

 

The firmware itself seems to run as-expected wrt. using UART with P0.18 and P0.19.

What is the VDD_GPIO level on your custom board? Could it be that there is a mismatch between the voltage levels on your USB/UART and the nRF?

 

Kind regards,

Håkon

[Yano]

Hi Håkon,

I was just thinking the same!

Before I read your post I had just checked it.

I had modified our USB interface to work with 1.8V and of course our hardware is working at 3.3V

So it worked fine with the DK but not our hardware.

So I am getting a response!!

A few more questions:

1. Is there a way to start the AT client in code, so the test house don't have to use a terminal to start it?

2. I need to see if it is working (e.g. getting responses back from cells) is there an AT command I can use?

3. Do I need the overlay in the SPM (secure boot) project?

Sorry for hassling you I'm under a lot of pressure to get this into test tomorrow.

Thanks

Ian

[Håkon Alseth]

Hi Ian,

 

Yano said:

Sorry for hassling you I'm under a lot of pressure to get this into test tomorrow.

Don't worry about this. That is no problem at all, and I'm very happy to help you out.

 

Yano said:

I had modified our USB interface to work with 1.8V and of course our hardware is working at 3.3V

So it worked fine with the DK but not our hardware.

So I am getting a response!!

This is great to hear! Just to confirm: You can now communicate in LTE Link Monitor with your own hardware, and the FTDI USB/UART bridge?

 

 

Yano said:

1. Is there a way to start the AT client in code, so the test house don't have to use a terminal to start it?

 It is possible to hard code certain AT commands, but you usually do not want to do this, as you want to keep the firmware as versatile as possible, in case the test house needs to do certain RF testing on other bands etc.

The easiest thing is to use the at_client, and manually call the AT commands, for instance AT%XRFTEST for RF PHY evaluation:

https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/production_test/xrftest_set.html?cp=2_1_10_1_0

 

Yano said:

2. I need to see if it is working (e.g. getting responses back from cells) is there an AT command I can use?

From the LTE Network? AT+CEREG can give you the network registration status: https://infocenter.nordicsemi.com/topic/ref_at_commands/REF/at_commands/nw_service/cereg.html?cp=2_1_7_9

 

Yano said:

3. Do I need the overlay in the SPM (secure boot) project?

 This is not directly needed. By adjusting your at_client/CMakeLists.txt file and adding this:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/${BOARD}.overlay")
  set(mcuboot_DTC_OVERLAY_FILE "${CMAKE_CURRENT_SOURCE_DIR}/${BOARD}.overlay")
  set(spm_DTC_OVERLAY_FILE "${CMAKE_CURRENT_SOURCE_DIR}/${BOARD}.overlay")
endif()

 

Then you are telling the multi-build system to also include your $(BOARD).overlay file to be applied for spm and potentially mcuboot (if present).

This is the equivalent operation to manually going into the spm project and pasting your $(BOARD-NOT_NS).overlay file into that directory.

 

As your at_client is setup at this moment, it successfully setup the uart pins to P0.18/P0.19.

 

Kind regards,

Håkon

[Yano]

Hi Hakon,

It's been a bit stressful with this deadline, thanks for all you help!

I can't talk to our device through LTE Link Monitor with our own hardware, to do that I need to use a terminal application.

First of all I've moved to a Prolific USB/UART bridge instead of the FTDI one (for now) but it was the same with that bridge.

Here is a test sequence:

1. start up our terminal application (Tera Term VT) and connect to com 9 (Prolific).

2. Power cycle the board.

3. Get boot message on screen.

4. Send AT command and get OK response.

5. Close Tera Term.

6. Connect to same com 9 using LTE monitor.

7. Send AT command get timeout error

8. Power cycle the board.

9. Get boot message

10. Send AT command get timeout error again.

11. Close device in LTE monitor

12. Open Tera Term back up and connect to com 9

13. Send AT command and get OK response.

14. Power cycle the board.

15. Get boot message on screen.

16. Send AT command and get OK response.

17. Close Tera Term.

I've scoped it and I can confirm LTE link monitor is not sending commands but Tera Term is?!

I can't be sure but I think there's something odd happening with LTE Link monitor (V1.1.10). BTW Auto device/port filter is not selected.

Any ideas?

Ian

[Håkon Alseth]

Hi Ian,

 

Yano said:

I've scoped it and I can confirm LTE link monitor is not sending commands but Tera Term is?!

Yano said:

First of all I've moved to a Prolific USB/UART bridge instead of the FTDI one (for now) but it was the same with that bridge.

It is very good to hear that the usb/uart adapters themselves work with various other terminal programs.

 I have created a bug internally on this matter. based on the test procedure that you have gone through, everything points to the LTE Link Monitor not properly handling sending data from the PC -> USB/UART adapter.

 

The best option as of now, is to use a generic terminal application to issue the specific AT commands required by the test house (usually AT%XRFTEST, and maybe a test to connect to a network via AT+CFUN=1).

 

Please let me know if you run into any issues with the testing procedure.

 

Kind regards,

Håkon