Configuring UART_1 for nRF9160

[Adeel]

Hi Dev Team,

I was working with the nRF9160 and started off with the basic UART sample found here : https://github.com/Rallare/fw-nrfconnect-nrf/tree/nrf9160_samples/samples/nrf9160/uart

I wanted to configure the UART_1 to connect to an external sensor, and I followed some links : https://devzone.nordicsemi.com/f/nordic-q-a/45476/connecting-uart1-to-a-periph-on-nrf9160-dk/178988#178988, https://devzone.nordicsemi.com/f/nordic-q-a/57199/using-the-nrf9160-to-send-and-receive-data-over-rs485-using-uart and changed the prj.conf file and the overlays file. 

prj.conf:

CONFIG_NEWLIB_LIBC=y
CONFIG_LIBLIGHTMODBUS=y


CONFIG_SERIAL=y
CONFIG_TRUSTED_EXECUTION_NONSECURE=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_MAIN_STACK_SIZE=4096

CONFIG_COMPILER_OPT="-DNRFX_UARTE_ENABLED=1 -DNRFX_UARTE0_ENABLED=1"


CONFIG_UART_1_NRF_UARTE=y

CONFIG_UART_1_NRF_FLOW_CONTROL=y

#CONFIG_BOARD_NRF9160DK_UART0_ARDUINO=y

#CONFIG_BOARD_NRF9160DK_UART0_VCOM=n

nrf9160dk_nrf9160ns.overlay:

/* Needed to get NRF_PWMn defined. */
&pwm1 {
	status = "okay";
};

&pwm2 {
	status = "okay";
};

&pwm3 {
	status = "okay";
};


&uart1 {
	current-speed = <9600>;
	status = "okay";
	tx-pin = <1>;
	rx-pin = <0>;
	rts-pin = <14>;
	cts-pin = <15>;
};

&uart0 {
	current-speed = <9600>;
	status = "ok";
	tx-pin = <10>;
	rx-pin = <11>;
	rts-pin = <12>;
	cts-pin = <13>;
};

The same is defined as an nrf9160dk_nrf9160.overlay file in the SPM folder.

When I try to build my application, I get a Kconfig error regarding the CONFIG_UART_1_NRF_UARTE=y. Could you help me understand what more could be required to change for it to work for UART_0.

Regards,

Adeel.

[Simon]

I've heard that there have been some issues using pin 0 and 1, and I will look into that tomorrow. In the meanwhile, you could try with some other pins.

Could you try to enable logging: #include <sys/printk.h> in main.c and CONFIG_SERIAL=y in prj.conf? Then open Termite and see if you get "[UART] Failed to get device!\n".

Attaching a logic analyzer (if you have one) is also very helpful when debugging issues with UART.

Best regards,

Simon

[Adeel]

Hi Simon,

I have changed the Tx, Rx pins to 12, 13 now. I tried to listen to the data on Termite. 

Is there any particular command I could use to see if the data is being transmitted ?

I tried using : gpio_pin_configure(gpio, RS485_SWITCH_PIN1 //Tx, GPIO_OUTPUT);

                     gpio_pin_set(gpio, RS485_SWITCH_PIN1, 1);

Does this transmit a high value on pin 12 which is my current Tx now ?

Regards,

Adeel. 

[Simon]

4456.uart_main.zip

Could you test the example below with NCS v1.3.0 and build for nrf9160dk_nrf9160ns. In this sample UART2 is used, but the approach should be the same for UART1.

Connect P0.21 to P0.19 and P0.18 to P0.17 on the nRF9160DK to enable loopback.

If you get that to work, you can modify the sample to work with your particular sensor.

Best regards,

Simon

[Adeel]

Hi Simon,

Thanks for the example. I was trying it out and I am trying to use UART_2 now.

Do I need to also flash my nRF52840 board with : CONFIG_BOARD_NRF9160DK_UART2_ARDUINO=y
CONFIG_BOARD_NRF9160DK_UART2_VCOM=n. I think its not necessary as I dint find this configuration anywhere but asking to make sure about it. 

I was trying out the example but I am stuck in another error in the SPM file. 

The log file is attached:

Building ‘C:/Users/adeel/ncs/v1.3.0/zephyr/include/dt-bindings/gpio/gpio.h’ from solution ‘build’ in configuration ‘Common’
Building ‘C:/Users/adeel/ncs/v1.3.0/zephyr/include/dt-bindings/i2c/i2c.h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/misc/generated/subsystems.json’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/misc/generated/syscalls.json’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/parse_syscalls_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/parse_syscalls_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/include/generated/driver-validation.h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/driver_validation_h_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/driver_validation_h_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/include/generated/kobj-types-enum.h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/include/generated/otype-to-str.h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/kobj_types_h_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/kobj_types_h_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/include/generated/syscall_list.h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/syscall_list_h_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/include/generated/syscall_dispatch.c’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/syscall_list_h_target’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_offsets’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/offsets.dir/arch/arm/core/offsets/offsets.c.obj’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/offsets’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/include/generated/offsets.h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/offsets_h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/offsets_h’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/zephyr_generated_headers’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_app’ from solution ‘build’ in configuration ‘Common’
Building ‘app/libapp.a’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_zephyr’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/libzephyr.a’ from solution ‘build’ in configuration ‘Common’
Building ‘C:/Users/adeel/ncs/v1.3.0/zephyr/misc/empty_file.c’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_..__modules__hal__nordic’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_..__nrf__drivers__hw_cc310’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_..__nrf__lib__fatal_error’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_..__nrf__subsys__fw_info’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_arch__arm__core__aarch32’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_arch__arm__core__aarch32__cortex_m’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_arch__arm__core__aarch32__cortex_m__cmse’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_arch__arm__core__aarch32__cortex_m__mpu’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_arch__arm__core__aarch32__cortex_m__tz’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_arch__common’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_drivers__gpio’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_drivers__serial’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_kernel’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_lib__libc__minimal’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_lib__posix’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_mbedcrypto_cc310_noglue’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_mbedcrypto_cc310’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_mbedcrypto_shared’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_mbedtls_base_vanilla’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_soc__arm__common__cortex_m’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/linker.cmd’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/CMakeFiles/linker_script_target’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/linker_script_target’ from solution ‘build’ in configuration ‘Common’
Building ‘cmake_object_order_depends_target_zephyr_prebuilt’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/arch/common/libarch__common.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/arch/arch/arm/core/aarch32/cortex_m/mpu/libarch__arm__core__aarch32__cortex_m__mpu.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/arch/arch/arm/core/aarch32/cortex_m/cmse/libarch__arm__core__aarch32__cortex_m__cmse.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/arch/arch/arm/core/aarch32/cortex_m/tz/libarch__arm__core__aarch32__cortex_m__tz.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/lib/libc/minimal/liblib__libc__minimal.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/lib/posix/liblib__posix.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/drivers/gpio/libdrivers__gpio.a’ from solution ‘build’ in configuration ‘Common’
Building ‘zephyr/drivers/serial/libdrivers__serial.a’ from solution ‘build’ in configuration ‘Common’
Building ‘modules/nrf/lib/fatal_error/lib..__nrf__lib__fatal_error.a’ from solution ‘build’ in configuration ‘Common’
Building ‘modules/nrf/subsys/fw_info/lib..__nrf__subsys__fw_info.a’ from solution ‘build’ in configuration ‘Common’
Building ‘modules/nrf/drivers/hw_cc310/lib..__nrf__drivers__hw_cc310.a’ from solution ‘build’ in configuration ‘Common’
Building ‘modules/nrfxlib/nrf_security/src/mbedtls/cc310/libmbedcrypto_cc310_noglue.a’ from solution ‘build’ in configuration ‘Common’
1> Compiling ‘ecjpake.c’
1> C:/Users/adeel/ncs/v1.3.0/mbedtls/library/ecjpake.c:30:10: error: #include expects "FILENAME" or <FILENAME>
Build failed

How can I get rid of this error as this hampers my SPM file compiling now. I tried searching and found this post: https://devzone.nordicsemi.com/f/nordic-q-a/63888/there-is-a-bug-in-sdk-1-3-0-when-compile-the-mbedtls-under-the-path-of-modules-nrfxlib-nrf_security-src-mbedtls-i-get-the-following-error-mbedtls-library-chacha20-c-29-10-error-include-expects-filename-or but I did not understand what to do. Could you help me around in this fix as I think the SPM is an important configuration for external UART communication. 

Regards,

Adeel. 

[Adeel]

Hi Simon,

I was able to run your example and I think the loopback works.

I can see the send and receive at the same COM port. Just to start off sending data externally, I want to send an ASCII string externally and receive it on an external console. 

4760.hello_world.zip

I tried this example but the string "AT, Test" was not transmitted externally. Could you suggest me how to go about sending some strings externally to check the UART.

Also, is my SPM build error hampering the functionality of external communication ? If so, how could I get rid of that.

Regards,

Adeel.