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
Hi Håkon,
For now I'm assuming there is something funny going on with the LTE Link monitor and we can deal with this seperatly.
All we need to do is get the unit in for test on Friday morning.
For this I don't need to upload certs etc. I only need to start it up AT+CFUN=1.
So I have moved over to our hardware and modified the TX/RX ports to 18 and 19.
When the boards start up all I get is this (below) and there is no response to my AT commands.
*** Booting Zephyr OS build v2.4.99-ncs1 ***
The AT host sample started
I think these just printk debug outputs and we're not connected to the AT command interface?
Is UART 0 the correct port?
Maybe my setup is incorrect?
Are there conflicting ports?
Project is attached...
Any ideas please.
P.S. Can you please give this your top priority as this goes into testing Friday morning.
Thanks Ianat_client.zip
Looking at other cases there seemed to be need to set the appropriate overlay in the SPM (secure boot) project.
I also tried that and it did not solve things, files attached.
I also tried a second PCB it has the same error and I have scoped the signal to the nRF9160 so I think hardware is not the issue.
Ian
Hi Ian,
Yano said:Looking at other cases there seemed to be need to set the appropriate overlay in the SPM (secure boot) project.
I also tried that and it did not solve things, files attached.
I also tried a second PCB it has the same error and I have scoped the signal to the nRF9160 so I think hardware is not the issue.
As the other terminal options work as expected, I think you have all the hardware and firmware related setup correct, and this looks like an issue with LTE Link monitor wrt. this specific USB-UART adapter.
If you have scoped the pins, tested other terminals and all looks to be working at that point; everything points to an issue on our PC software, which I must apologize for.
Is it a possibility to use another terminal than LTE Link monitor for tomorrows purpose?
Kind regards,
Håkon
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
0066.nrf9160dk_nrf9160.overlay
#
# 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
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 startedI 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