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]

In the documentation you linked it says:

Before programming the sample, configure it to provision the certificates from the certificates.h file (PROVISION_CERTIFICATES) and to use a different security tag (CLOUD_CERT_SEC_TAG).

When should these switches be put and do you have an example of the format?

Thanks

Ian

[Yano]

It looks like there is a bit of a mix-up between aws_iot and aws_fota!

The documentation also seems to be mixed up between these.

aws_fota seems to have options in kconfig but for some reason aws_iot doesn't?

It's very confusing, I don't know what switches to use.

Should I move over to use aws_fota?

If I do will I still be able to subscribe and publish topics as well as doing an update?

Thanks Ian 

 

[Håkon Alseth]

Hi Ian,

 

Yano said:

It looks like there is a bit of a mix-up between aws_iot and aws_fota!

The samples are different, but both connect to AWS services, so the sequence of events, especially wrt. certificates, is equal algorithm wise; but they show different roads to Rome.

 

My former answer shows you the two ways of provisioning certificates.

This is the implementation that is used in aws_fota:

https://github.com/nrfconnect/sdk-nrf/blob/v1.5.0/samples/nrf9160/aws_fota/src/main.c#L327-L372

If you choose this method, you add your certificates to the header file:

https://github.com/nrfconnect/sdk-nrf/blob/v1.5.0/samples/nrf9160/aws_fota/src/certificates.h

 

They should then hold the format as I described underneath with quotes and newlines.

Once you write the certificates to a specific sec_tag, you can re-use the tag a new firmware, as the certificates are then stored in the modem.

 

Kind regards,

Håkon

[Yano]

Hi Håkon,

Thanks!

I have them both going now using the certificate.h method.

Do you have a timeline for the fix to LTE-link serial?

One last question, which of the two aws samples is best to use as the basis of a project?

We need our code to be able to publish and subscribe initially (quickly) but fota capability will be needed at some stage.

Thanks

Ian

[Håkon Alseth]

Hi Ian,

 

Yano said:

Thanks!

I have them both going now using the certificate.h method.

Great to hear! 

 

Yano said:

Do you have a timeline for the fix to LTE-link serial?

 Unfortunately, I do not have a timeline. I have made the team aware of the issue, and asked them to plan this into their next sprint.

 

Yano said:

One last question, which of the two aws samples is best to use as the basis of a project?

We need our code to be able to publish and subscribe initially (quickly) but fota capability will be needed at some stage.

 This highly depends on what your application is expected to do.

The aws_iot sample shows how to connect and communicate over AWS IoT message broker, while the aws_fota shows how to perform an over-the-air firmware update of an nRF9160 device via MQTT and HTTP. These samples also showcase FOTA features over http: https://github.com/nrfconnect/sdk-nrf/tree/master/samples/nrf9160/http_update

You can look at several samples, and implement specific features from samples into your own application, based on your requirements. If your application needs to connect to a generic mqtt broker, the mqtt_simple sample could be a good starting point.

 

Kind regards,

Håkon