nRF9160 Reboots when Accessing UART2

I have a custom board with a GPS chip and trying to communicate via UART2 on a nRF9160 using NCS 2.1.2.

When I try to write to the UART, the board reboots with no error messages. This was working when I had it set to

UART0 but changing to UART2 started this issue. Any thoughts would be appreciated.

DTS:

&uart0 {
	status = "okay";
	current-speed = <115200>;
	pinctrl-0 = <&uart0_default>;
	pinctrl-1 = <&uart0_sleep>;
	pinctrl-names = "default", "sleep";
};

&uart2 {
	status = "okay";
	current-speed = <9600>;
   label = "UART_2";
	pinctrl-0 = <&uart2_default>;
	pinctrl-1 = <&uart2_sleep>;
	pinctrl-names = "default", "sleep";
};

prj.conf

CONFIG_SERIAL=y

CONFIG_CONSOLE=y
CONFIG_UART_CONSOLE=y

# UART
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=n
CONFIG_UART_2_ASYNC=n
CONFIG_UART_ASYNC_API=n
CONFIG_UART_2_NRF_HW_ASYNC=n
CONFIG_NRFX_UARTE2=y

Basic UART code:

void initUart() {
   uart = device_get_binding("UART_2");
	__ASSERT(uart, "Failed to get UART device");
	interrupt_driven(uart);
}

uint16_t writeUARTblock(const uint8_t *buf_block, uint16_t len) {
uint16_t written = 0;

   while (written < len) {
      if (k_fifo_is_empty(&tx_fifo)) {
	      struct tx_uart_data_t *fifo_buf = k_malloc(sizeof(struct tx_uart_data_t));
         if (len - written < UART_BUF_SIZE) {
            fifo_buf->len = len - written;
         } else
            fifo_buf->len = UART_BUF_SIZE;
         memcpy(fifo_buf->data, &buf_block[written], fifo_buf->len);
         written += fifo_buf->len;
	      k_fifo_put(&tx_fifo, fifo_buf);
	      uart_irq_tx_enable(uart);

         k_msleep(BUF_DELAY);
      } else  
         k_msleep(BUF_DELAY);
   }

	return written;
}

Program output:

*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
SerialTest has started
LEDs Enabled HIGH
[00:00:00.488,342] <inf> regulator_fixed: gps-hw-s onoff: 0
[00:00:00.494,689] <inf> regulator_fixed: gps-hw-r onoff: 0
[00:00:00.501,037] <inf> regulator_fixed: gps-pwr-en onoff: 0
[00:00:00.510,070] <inf> lis2dh: lis2dh@18: int1 on [email protected]
[00:00:00.517,059] <inf> lis2dh: lis2dh@18: int2 on [email protected]
[00:00:00.526,428] <inf> lis2dh: fs=2, odr=0x4 lp_en=0x0 scale=9576
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
SerialTest has started
LEDs Enabled HIGH
[00:00:00.488,677] <inf> regulator_fixed: gps-hw-s onoff: 0
[00:00:00.495,025] <inf> regulator_fixed: gps-hw-r onoff: 0
[00:00:00.501,373] <inf> regulator_fixed: gps-pwr-en onoff: 0
[00:00:00.510,437] <inf> lis2dh: lis2dh@18: int1 on [email protected]
[00:00:00.517,425] <inf> lis2dh: lis2dh@18: int2 on [email protected]
[00:00:00.526,824] <inf> lis2dh: fs=2, odr=0x4 lp_en=0x0 scale=9576
*** Booting Zephyr OS build v3.1.99-ncs1-1  ***
SerialTest has started
LEDs Enabled HIGH

Parents Reply
  • Thank you for reading this out.

    From the Product Specification, we can see that '00010001' indicates both reasons 'A' and 'E'.

    RESETREAS is cumulative, so two reasons for reset are recorded. Please keep in mind that the reset reason register is not cleared automatically. You will have to clear it in order to know whether it has happened again.

    'A' corresponds to "Reset from pin reset detected". Does this make any sense? Was the resetpin used intentionally? How is the resetpin connected? Is the device battery-powered? Have you measured the VDD voltage level?

    'E' corresponds to "Reset from AIRCR.SYSRESETREQ detected". The SiP performs a "Soft reset" when AIRCR.SYSRESETREQ is set.

    https://infocenter.nordicsemi.com/topic/ps_nrf9160/pmureset.html

    Looking at the RESETREAS register, we can see that this reset reason is an SREQ(software/soft reset, i.e. NVIC_SystemReset()), so your code likely runs into an error and resets. To debug this further, try:

    CONFIG_RESET_ON_FATAL_ERROR=n

    CONFIG_DEBUG=y

    You could also try:

    CONFIG_REBOOT=n

Children
Related