Configuring UART_1 for nRF9160

RE: Configuring UART_1 for nRF9160

Simon — Mon, 09 Nov 2020 09:00:48 GMT

Nice! I'm happy you finally made it work👍

Best regards,

Simon

RE: Configuring UART_1 for nRF9160

Adeel — Mon, 09 Nov 2020 08:40:02 GMT

Hi Simon,

Thanks or the tip. Instead of that, I got the RS485 module to work with 3V and so I was able to transmit and receive from the module 🙂.

Thanks for the help. I finally got things running at my end.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Fri, 06 Nov 2020 14:23:38 GMT

If you set the VDD IO switch to 3V the GPIO will output 3V and if you set it to 1v8, it will output 1.8v. I tested this with a multimeter and P0.28, I've attached the sample below:

devzone.nordicsemi.com/.../3124.toggle_5F00_gpio_5F00_regs.7z

However, according to Modbus (RS-485) Using Arduino, you should connect RE and DE to 5V in order to use the RS485 as a transmitter. The GPIOs only output 3v. I think you can solve this using a FET: https://devzone.nordicsemi.com/f/nordic-q-a/10542/5-volts-output-on-nrf51-dk-pin

Best regards,

Simon

RE: Configuring UART_1 for nRF9160

Adeel — Tue, 03 Nov 2020 10:17:42 GMT

Hi Simon,

Regarding the same, I had a query regarding the GPIO Pins.

I have now tied up my DE / RE to 1 pin (Pin 0.12) and configured that pin as an output (nrf_gpio_cfg_output(12)). So when I transmit, I keep this pin to High (nrf_gpio_pin_set(12)) and after my uart_fifo_fill(), I keep a certain delay and pull the pin low (nrf_gpio_pin_clear(12)) to enable the receive.

nrf_gpio_cfg_output(12);

while(1){

        nrf_gpio_pin_set(12);
            
        uart_fifo_fill(uart, (uint8_t*)(mstatus.request.frame), mstatus.request.length);   
               

        k_sleep(K_SECONDS(2));

        nrf_gpio_pin_clear(12);
            }

However, I see that the GPIO pins dont work the way I need. As in, the pin does not change from transmit to receive. Is it due to the voltage mismatch ?

I read the datsasheet of the MAX-485 device that I am using and it says it needs more than 2V.

Does the GPIO pins normally output 1.8V or 3V in nrf9160DK ?

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Adeel — Mon, 02 Nov 2020 14:46:50 GMT

Hi Simon,

Thanks for the tip :). I was finally able to communicate through the RS-485 module. The problem was with the voltage mismatch. The nrf9160dk has a switch to change between 1.8 and 3V for the I/O.

As a next step, I was trying to enable my receiver as well through my GPIO's. What is the normal voltage output that I can get through my GPIO ?

Will the logic of enabling and disabling my RS-485 DE and RE be the same as in this example : https://devzone.nordicsemi.com/f/nordic-q-a/55059/nrf51822-with-modbus-ttl-to-rs485/223289#223289

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Fri, 30 Oct 2020 20:30:49 GMT

Try connecting all the pins to the same board (nrf9160dk), as shown in the image. Not to the Arduino's

RE: Configuring UART_1 for nRF9160

Adeel — Fri, 30 Oct 2020 17:15:34 GMT

Hi Simon,

I tried this config that you told me. Attaching the picture of it.

I connected Tx to my configured input P0.10. I also changed the number in the overlay.

DE,RE are connected to 5V of other Arduino.

I still don't see anything out.

I was expecting the received strings at the receiver device.

Any inputs ? I just changed the Tx pin as P0.10 in overlay and baudrate to 9600. My receiver device has the same baud arte of 9600.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Fri, 30 Oct 2020 16:20:47 GMT

Why don't you start really simple, follow these steps:

Program this sample onto the nRF9160: devzone.nordicsemi.com/.../0755.uart_5F00_main.zip
- Using NCS v1.3.0 an the board nrf9160dk_nrf9160ns
- I disabled flow control as well
Connect the nRF9160 to the RS485 as shown in the image below:

Best regards,

Simon

RE: Configuring UART_1 for nRF9160

Adeel — Thu, 29 Oct 2020 15:10:27 GMT

Hi Simon,

Thanks a lot. Sure, It would be really helpful 🙂.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Thu, 29 Oct 2020 15:07:19 GMT

I'm really sorry for the delay on this, I've been quite busy lately. I will look into this tomorrow.

Best regards,

Simon

RE: Configuring UART_1 for nRF9160

Adeel — Thu, 29 Oct 2020 15:01:26 GMT

Hi Simon,

Any help on this would be very useful :).

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Adeel — Mon, 26 Oct 2020 12:15:52 GMT

Hi Simon,

Just to catch up on this, I read about the enable and the blocking mode. I believe the blocking mode after transmission is not being set up.

I have enabled the DE and RE pin before transmission and I wait for a certain time before making it low.

I found this case quite relevant: https://devzone.nordicsemi.com/f/nordic-q-a/55059/nrf51822-with-modbus-ttl-to-rs485/223289#223289

But it has handlers which I did not find compatible with nrf9160. Its for the nRF52 series.

Could you just help me in modifying my above attached example that could be compatible with the nrf9160DK. I would really appreciate the help in this.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Adeel — Thu, 22 Oct 2020 13:02:11 GMT

Hi Simon,

Not really. I could not figure out the exact trouble with it. The loopback works with Tx to Rx. So I assume that the string is atleast reaching the Tx.

I followed this post and got a simple example : https://devzone.nordicsemi.com/f/nordic-q-a/47218/continuously-package-send-on-uart

The string transmission to an outside serial interface is not happening. I wonder what could be the cause.

When I just take out and put back my Tx pin on the board, I see random data on the serial analyser. I am sure the RS485 configuration is correct because for now, I just want to transmit the string. The DE is kept high for that and RE high as well (Negative logic). Any insights would be helpful.

I hope there is no mistake in my UART config atleast.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Thu, 22 Oct 2020 11:41:17 GMT

Sorry for the delay on this, I've been quite busy lately. I will look into it today. Have you made any progress?

Best regards,

Simon

RE: Configuring UART_1 for nRF9160

Adeel — Mon, 19 Oct 2020 16:39:26 GMT

Hi Simon,

I tried another example that looked much simpler and I just wanted to transmit things out of the UART.

The code is pretty straight forward as well to understand.

static K_FIFO_DEFINE(fifo_uart_tx_data);
static K_FIFO_DEFINE(fifo_uart_rx_data);

struct uart_data_t {
	void  *fifo_reserved;
	u8_t    data[1024];
	u16_t   len;
};

static struct device *uart_dev;


void uart_cb(struct device *x)
{
	uart_irq_update(x); // Start processing interrupts in ISR.
	int data_length = 0;

	if (uart_irq_rx_ready(x)) { // Check if UART RX buffer has a received char.               
		data_length = uart_fifo_read(x, uart_buf, sizeof(uart_buf)); // Read data from FIFO.
		uart_buf[data_length] = 0;
                }
                printk("Received data is:%s\r\n", uart_buf);

            if (uart_irq_tx_ready(x)) {
            
                struct uart_data_t *buf = 
                k_fifo_get(&fifo_uart_tx_data, K_NO_WAIT);
              u16_t written = 0;

              /* Nothing in the FIFO, nothing to send */
		if (!buf) {
			uart_irq_tx_disable(x);
			return;
		}

                while (buf->len > written) {
			written += uart_fifo_fill(x,
						  &buf->data[written],
						  buf->len - written);
                       uart_tx(uart_dev, buf, 5, 5000);
		}

                while (!uart_irq_tx_complete(x)) {
			/* Wait for the last byte to get
			 * shifted out of the module
			 */
		}

		if (k_fifo_is_empty(&fifo_uart_tx_data)) {
			uart_irq_tx_disable(x);
		}

                k_free(buf);

      
              
}
}

void main(void)
{
       

        uart_dev = device_get_binding("UART_2"); 
        if (!uart_dev) {
		printk("error\r\n");
	}          

        uart_irq_rx_disable(uart_dev);
        uart_irq_callback_set(uart_dev, uart_cb); // Set UART interrupt callback
        uart_irq_rx_enable(uart_dev);

        uart_irq_tx_enable(uart_dev);

        printk("Testing1: \n");              
        uart_fifo_fill(uart_dev, "AB" ,sizeof("AB"));
        
        k_sleep(K_MSEC(100));


        
	while (1) {
                
                  k_cpu_idle();             
                
	}
}

Still, I don't see the data out on my analyzer. I have a serial interface analyzer where I view the string. I tried with Arduino and that worked just by a transmit signal.

So, I am unsure as to what could be the causes for it. I can see the loopback data in this example as well when I connect my Tx to Rx.

(1). I have the correct overlay files both in spm (nrf9160dk_nrf9160) as well as in my folder (nrf9160dk_nrf9160ns)

&uart2 {
	compatible = "nordic,nrf-uarte";
	status = "okay";
	current-speed = <9600>;
	tx-pin = <10>;
	rx-pin = <11>;
	rts-pin = <12>;
	cts-pin = <13>;
	hw-flow-control;
};

&uart1 {
	status = "disabled";
};

I have also changed the configuration in the nrf9160dk_nrf9160_common.dts file in : C:\Users\adeel\ncs\v1.3.0\zephyr\boards\arm\nrf9160dk_nrf9160.

My prj config file is :

CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_ASYNC_API=y
CONFIG_TRUSTED_EXECUTION_NONSECURE=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_MAIN_STACK_SIZE=4096
CONFIG_UART_2_NRF_FLOW_CONTROL=y

I am unsure of what could be the issue ? The configuration or the code.

I just want to transmit the string set in uart_fifo_fill() function in my code to check the UART connection.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Adeel — Fri, 16 Oct 2020 09:40:33 GMT

Hi Simon,

As I understood from the RS-485 transmit and receive logic, I tried to implement it in the following way:

#include <zephyr.h>
#include <sys/printk.h>
#include <zephyr.h>
#include <string.h>
#include <drivers/uart.h>
#include "nrf.h"
#include <hal/nrf_gpio.h>

#include <drivers/gpio.h>

#define GPIO_PORT "GPIO_0"

#define RS485_TRANSMIT       1
#define RS485_RECEIVE        0
#define RS485_SWITCH_PIN1    10  // Tx
#define RS485_SWITCH_PIN2    11  // Rx
#define MAX485_DE      12    // DE pin (rts)
#define MAX485_RE_NEG  13    // RE pin (cts)

static u8_t uart_buf[1024];
static struct device *uart_dev;


void uart_cb(struct device *_uart)
{
	uart_irq_update(_uart); // Start processing interrupts in ISR.
	int data_length = 0;
        

	if (uart_irq_rx_ready(_uart)) { // Check if UART RX buffer has a received char.               
		data_length = uart_fifo_read(_uart, uart_buf, sizeof(uart_buf)); // Read data from FIFO.
		uart_buf[data_length] = 0;
                }
                printk("Received data is:%s\r\n", uart_buf); // Output received here

}


void uart_send_str(struct device *uart, char *str){
   
    printk("callback!\r\n");  
    
    nrf_gpio_pin_set(MAX485_DE);   // Setting it High before Tx
    nrf_gpio_pin_set(MAX485_RE_NEG);  // Setting it low before Tx
    u32_t len = strlen(str);
    while (len--) {
        uart_poll_out(uart, *str++); // Transmission
        //uart_fifo_fill(uart, str, 2);

    k_sleep(K_MSEC(5000));   // Delay 
    nrf_gpio_pin_clear(MAX485_DE);  // Setting low for reception
    nrf_gpio_pin_clear(MAX485_RE_NEG);  // Setting High for reception
    
    }
}

void main(void)
{
        char *command = "OKAZZZ";      // String to be transmitted out
        printk("Hello, World!\r\n");

        uart_dev = device_get_binding("UART_2"); 
        if (!uart_dev) {
		printk("error\r\n");
	}          

        uart_irq_rx_disable(uart_dev);
        uart_irq_callback_set(uart_dev, uart_cb); // Set UART interrupt callback
        uart_irq_rx_enable(uart_dev);

        nrf_gpio_cfg_output(MAX485_DE); // Set DE as Output
        nrf_gpio_cfg_output(MAX485_RE_NEG); // Set RE as Output

	while (1) {
                printk("loop head\r\n");
                uart_send_str(uart_dev, command); // Function to transmit the data
	}
}

My overlay file is as follows: nrf9160dk_nrf9160ns.overlay

&uart2 {
	compatible = "nordic,nrf-uarte";
	status = "okay";
	current-speed = <115200>;
	tx-pin = <10>;
	rx-pin = <11>;
	rts-pin = <12>;
	cts-pin = <13>;
	hw-flow-control;
};

&uart1 {
	status = "disabled";
};

Could you look at the logic to see if this is the right way to enable / disable the DE/RE pins. The hardware connections are as per the overlay file.

The loopback works when I only connect Tx to Rx directly, so I guess the issue is only with the DE/RE pins. The loopback data is:

I think I am close but just need some advice in enabling / disabling DE/RE pins in the code. Thanks for the help 🙂.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Adeel — Thu, 15 Oct 2020 19:53:46 GMT

Hi Simon,

I did that as well. I tried to set both the pins (RE-DE) to high before transmission so that DE is enabled and RE is disabled. Then after the transmission, I tried to give a bit of a delay and then cleared both the pins to low so that DE is disabled and RE gets enabled.

I dont have a logic analyzer right now but will try to manage it.

Are there any examples of RS485 communication for nRF9160DK that I could refer to for more info.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Thu, 15 Oct 2020 13:51:26 GMT

Try to set RE high using nrf_gpio_pin_set() as well. As you can see here, setting RE high will disable the receiver (RE is LOW enable whle DE is high enable).

Do you have a logic analyzer? Try attaching it to the lines to see what's actually going on.

Best regards,

Simon

RE: Configuring UART_1 for nRF9160

Adeel — Wed, 14 Oct 2020 16:26:11 GMT

Hi Simon,

I tried to follow this example to get an idea of how to work with RS-485 here.

https://devzone.nordicsemi.com/f/nordic-q-a/55059/nrf51822-with-modbus-ttl-to-rs485

I tried to configure the DE and RE as output through : nrf_gpio_cfg_output().

Then, before sending the string, I set DE high as: nrf_gpio_pin_set().

devzone.nordicsemi.com/.../5355.hello_5F00_world.rar

This is the example I am trying to modify. Can you just have a look to see if this is the right way to configure the DE/RE pins. Thanks for looking into this.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Adeel — Wed, 14 Oct 2020 14:43:33 GMT

Hi Simon,

It tried it but unfortunately it did not work :(.

Right now, I have my RE connected to ground and DE (Pin 12) set as high to enable transmit. I read a blog post that explained it quite clearly: https://electronics.stackexchange.com/questions/153500/correctly-using-re-and-de-with-rs485/153508

I did it so as to check whether I am receiving what I am sending. With this, I get some random transmission on my console but I receive the same on my nRF terminal as Received data: (which is through my uart_buf).

This happens when I move my DE pin a bit on pin 12 (Taking it out and putting it back in) :). That is when the data gets transmitted but it is random bits and not what I am sending.

I am a bit confused with the functionality.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Wed, 14 Oct 2020 14:08:01 GMT

I'm not too familiar with the RS485, but I tried to read up on it and gained some insight. Could you try the following connections:

nRF9160	RS485
5V	RE
5V	DE
TX	DI
5V	Vcc
GND (0V)	GND

Leave A and B as before.

This will not use the flow control pins, and you will not be able to receive any data. But do this to see if you are able to transmit the data.

Best regards

RE: Configuring UART_1 for nRF9160

Adeel — Wed, 14 Oct 2020 12:45:13 GMT

Okay, just an addition to it. I have my setup through a TTL_RS485 converter.

So, I assume my RTS-CTS (RE/DE) - (12,13) pins play a role in this. I tried setting the DE (12) to High before transmitting and made it low after the transmit is done and my CTS is set in receive mode thereafter.

devzone.nordicsemi.com/.../5148.hello_5F00_world.rar

Attaching my updated code if you could have a look at this.

I was looking for some working example for communication with RS-485 and nRF9160DK. I receive random values in my external console rather than my sent ASCII value.

Not sure why is it like that.

Regards,

Adeel.

RE: Configuring UART_1 for nRF9160

Simon — Wed, 14 Oct 2020 12:30:48 GMT

I'm looking into this right now. Will test the sample.

RE: Configuring UART_1 for nRF9160

Adeel — Mon, 12 Oct 2020 16:50:50 GMT

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.

devzone.nordicsemi.com/.../4760.hello_5F00_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.

RE: Configuring UART_1 for nRF9160

Adeel — Mon, 12 Oct 2020 16:02:53 GMT

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.