Serial Output for the Thingy:91 With Custom Firmware

[MJD093]

Hello,

I am currently tweaking the Thingy:91 to run a stripped down version of my custom application. I have been able to flash the device with the Thingy:91's sample at_client and asset_tracker applications that are floating about the DevZone. They both flash and I can see the output of the asset_tracker application on the Link Monitor program.

The board version is PCA20035 v1.0.0 with the dts set to nrf9160_pca20035_v0_3_0 (as it's the latest revision available in SDK v1.0.0).

When I flash the custom firmware, the device seems to run as expected. I can see the RGB LED change colour during the different states of the application but the serial output is blank. Is there something else that is needed in the set-up for the pca20035 that allows the serial port to work for the Link Monitor? Possibly something similar to how the nRF52840 on the PCA10090 can be set with CONFIG_BOARD_PCA10090_UART0_ARDUINO=y to run the messages over UART pins instead of the USB?

[Håkon Alseth]

Hi,

 

The UARTE0 pin out for the nrf9160_pca20035 is defined here:

https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/boards/arm/nrf9160_pca20035/nrf9160_pca20035_common.dts#L165

These pins go to the nRF52840, which acts as a USB-UART bridge.

 

Do you want to output the UART on other pins and not use the nRF52 as a bridge?

Note: to be able to select the COM port in LTE Link Monitor, you need to uncheck the "Auto device/port filter" in the bottom right corner, as described here:

https://infocenter.nordicsemi.com/topic/ug_thingy91/UG/thingy91/getting_started/connecting_lte_link_monitor.html?cp=10_0_2_0

 

Kind regards,

Håkon

[MJD093]

No, I would like it to function as a UART-USB bridge. The issue is that for my custom firmware, the device doesn't print to the link monitor. The device does print to the link monitor when it uses the pre-compiled Thingy:91 asset_tracker.

There must be something different between the custom firmware and the pre-compiled asset_tracker that allows the UART-USB output to show in the Link Monitor but not in the custom firmware.

[Håkon Alseth]

Does any of the other samples, like mqtt_simple, output anything on the UART when configured with BOARD=nrf9160_pca20035?

Can you share more info about your custom firmware, like the prj.conf and possible .overlay's that are applied?

 

Kind regards,

Håkon

[MJD093]

Hi Håkon,

Unfortunately none of the sample applications built for the nrf9160_pca20035_v0_3_0ns device print information to the Link Monitor. When I run the Thingy:91 pre-compiled Asset Tracker application, I can see this from the Link Monitor:

SPM: NS image at 0x18200
SPM: NS MSP at 0x2002d5a0
SPM: NS reset vector at 0x27c41
SPM: prepare to jump to Non-Secure image.
***** Booting Zephyr OS v1.14.99-ncs2 *****
[00:00:00.247,924] [0m<dbg> board_nonsecure.pca20035_magpio_configure: AT CMD: AT%XMODEMTRACE=0
[0m[00:00:00.257,934] [0m<dbg> board_nonsecure.pca20035_magpio_configure: AT RESP: OK
[0m[00:00:00.265,930] [0m<dbg> board_nonsecure.pca20035_magpio_configure: AT CMD: AT%XMAGPIO=1,1,1,7,1,746,803,2,698,748,2,1710,2200,3,824,894,4,880,960,5,791,849,7,1574,1577
[0m[00:00:00.281,982] [0m<dbg> board_nonsecure.pca20035_magpio_configure: AT RESP: OK
[0m[00:00:00.289,978] [0m<dbg> board_nonsecure.pca20035_magpio_configure: MAGPIO successfully configured
[0mAsset tracker started
[00:00:00.302,307] [0m<dbg> nrf_cloud_transport.nct_client_id_get: client_id = nrf-352656100434714
[0m[00:00:00.311,553] [0m<dbg> nrf_cloud_transport.nct_topics_populate: shadow_base_topic: $aws/things/nrf-352656100434714/shadow
[0m[00:00:00.323,211] [0m<dbg> nrf_cloud_transport.nct_topics_populate: accepted_topic: $aws/things/nrf-352656100434714/shadow/get/accepted
[0m[00:00:00.335,784] [0m<dbg> nrf_cloud_transport.nct_topics_populate: rejected_topic: $aws/things/nrf-352656100434714/shadow/get/rejected
[0m[00:00:00.348,327] [0m<dbg> nrf_cloud_transport.nct_topics_populate: update_delta_topic: $aws/things/nrf-352656100434714/shadow/update/delta
[0m[00:00:00.361,206] [0m<dbg> nrf_cloud_transport.nct_topics_populate: update_topic: $aws/things/nrf-352656100434714/shadow/update
[0m[00:00:00.373,077] [0m<dbg> nrf_cloud_transport.nct_topics_populate: shadow_get_topic: $aws/things/nrf-352656100434714/shadow/get
[0mConnecting to LTE network. This may take several minutes.
[00:00:46.473,144] [0m<dbg> lte_lc.at_handler: recv: +CEREG: 2,"FFFE","FFFFFFFF",7

The application is pretty simple and is a stripped down version of the main application I am building. Effectively this version will just alternate between GPS and NB-IoT every 2 minutes. It will launch into GPS when booted, acquire a fix, store it and after 2 minutes switch to LTE and send that fix by UDP.

I can tell that the application is working as I set the Blue LED to flash during GPS and then Green when in LTE. The device is clearly swapping between the two happily. The only issue is that the 'prink()'s are not displaying down the COM port.

The prj.conf:

# Use the development test RNG (not for production)
CONFIG_TEST_RANDOM_GENERATOR=y

# Networking, enable networking APIs
CONFIG_NETWORKING=y
CONFIG_NET_SOCKETS_OFFLOAD=y
CONFIG_NET_SOCKETS=y

# Allow Socket APIs to use POSIX names like socket(), send(), etc
# Careful with close(), close() only works on sockets when enabled
CONFIG_NET_SOCKETS_POSIX_NAMES=y

# BSD library
CONFIG_BSD_LIBRARY=y

# Main thread, reuse init stack
CONFIG_MAIN_THREAD_PRIORITY=4
CONFIG_MAIN_STACK_SIZE=4096

# Available memory for k_malloc
CONFIG_HEAP_MEM_POOL_SIZE=2048

# Enable stdout for printfs
CONFIG_STDOUT_CONSOLE=y

# Logging
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=4

# Build with newlib c library
CONFIG_NEWLIB_LIBC=y
CONFIG_NEWLIB_LIBC_FLOAT_PRINTF=y

# Enable non-secure firmware as Normal mode
CONFIG_TRUSTED_EXECUTION_NONSECURE=y

# Enable Flash Memory Management
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y

# Enable NVS File System
CONFIG_NVS=y
CONFIG_NVS_LOG_LEVEL_DBG=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y

# Include GPIO drivers
CONFIG_GPIO=y

# Enable options for serial drivers
CONFIG_SERIAL=y

# Enable UART Interrupt support
CONFIG_UART_INTERRUPT_DRIVEN=y

# Enable ADC config drivers, enable ADC 0
CONFIG_ADC=n
CONFIG_ADC_0=n

# Enable support for nrfx SAADC driver for nRF52 MCU series
# This is needed to run ADC code on the nRF91 series
CONFIG_ADC_NRFX_SAADC=n

# Include support for watchdogs
CONFIG_WATCHDOG=y

#Allow threads to use the Floating Point Unit Register
CONFIG_FLOAT=y

CONFIG_REBOOT=y

CONFIG_ASSERT=y
CONFIG_DEBUG=y
CONFIG_LOG_BACKEND_SHOW_COLOR=n
CONFIG_LOG_IMMEDIATE=y
CONFIG_LOG_STRDUP_MAX_STRING=128
CONFIG_BOARD_LOG_LEVEL_DBG=y

CONFIG_CONSOLE_SUBSYS=y
CONFIG_CONSOLE_HANDLER=y
CONFIG_CONSOLE_GETCHAR=y

The last two blocks of config options are taken from the pca20035_v0_3_0 asset tracker prj.conf

The overlay (nrf9160_pca20035_v0_3_0ns.overlay):

/* Needed to get NRF_UARTE2 and NRF_PWMn defined. */

&adc {
	status ="ok";
};

&timer0 {
	status = "ok";
};

&timer1 {
	status = "ok";
};

&timer2 {
	status = "ok";
};

&pwm0 {
	status = "ok";
};

&pwm1 {
	status = "ok";
};

&pwm2 {
	status = "ok";
};

&pwm3 {
	status = "ok";
};

This is copied into SPM as a non-secured overlay version as well.

[MJD093]

Looking more closely at each DTS file, it would appear that the basic pca20035.dts uses the v0.3.0 board layout anyway (#including them). I reconfigured the overlay for pca20035 for both secure and non-secure and the COM port is not spitting out my application printk()s.