Error in configuring UART pins in SDK2.3.0

[Sachin Rawat]

Hi there,

I have recently switched my complete "Bluetooth Peripheral" Project from the SDK version 1.9.1 to 2.3.0 

I have been facing some of the pin control issue for the UART, as I have observe you have change the way the UART is working and added the pinctrl functionality.

Previously on the 1.9.1, I was using the UART pins shown under.

&uart0 {
	rts-pin = < 0xff >;
	cts-pin = < 0xff >;
};

&uart2 {
	current-speed = <9600>;
	status = "okay";
	tx-pin = <4>;  
	rx-pin = <5>;
	rts-pin = < 0xff >;
	cts-pin = < 0xff >;
	rx-pull-up;
};

I am using this UART2 for communicating with the BMS(Battery management system), but now in the new SDK when using the same pin configuration, I am getting the error 

"d:\v2.3.0\zephyr\include\zephyr\toolchain\gcc.h:78:36: error: static assertion failed: "/soc/peripheral@50000000/uart@b000 defined without required pin configuration""

"d:\v2.3.0\zephyr\include\zephyr\toolchain\gcc.h:78:36: error: static assertion failed: "/soc/peripheral@50000000/uart@b000 has legacy *-pin properties defined although PINCTRL is enabled"

I am using SDK 2.3.0, and my board is the Nordic Thingy53.

Could you please advise on how to resolve this error and properly configure the UART on my SoC?

Regards 
Sachin

[RossJ]

I've not used device_get_binding() in my own code. Instead I use the device tree macros. So something like this...

static const struct device *bms_uart = DEVICE_DT_GET(DT_NODELABEL(uart2));

Note that uart2 is the node label defined in the devicetree fragment above. I'm not certain where the 'name' comes from which is the argument to device_get_bindings(). There are several ways to obtain the device pointer.

[Sachin Rawat]

After changing the code to this

static const struct device *bms_uart;

bms_uart = DEVICE_DT_GET(DT_NODELABEL(uart2)); 

if (bms_uart == NULL) {

    printk("Failed to get UART2 binding\n");    

    return;        

  }

I am getting the USAGE FAULT

*** Booting Zephyr OS build v3.2.99-ncs2 ***
00> [00:00:17.360,290] <inf> fs_nvs: nvs_mount: 8 Sectors of 4096 bytes
00> [00:00:17.360,931] <inf> fs_nvs: nvs_mount: alloc wra: 0, fd0
00> [00:00:17.361,572] <inf> fs_nvs: nvs_mount: data wra: 0, 1a
00> Bluetooth initialized as slave
00> [00:00:17.380,798] <err> os: usage_fault: ***** USAGE FAULT *****
00> [00:00:17.381,408] <err> os: usage_fault:   Illegal use of the EPSR
00> [00:00:17.382,019] <err> os: esf_dump: r0/a1:  0x00046bf4  r1/a2:  0x20006ecc  r2/a3:  0x0000000d
00> [00:00:17.382,873] <err> os: esf_dump: r3/a4:  0x000003e8 r12/ip:  0x00000000 r14/lr:  0x0001aab5
00> [00:00:17.383,697] <err> os: esf_dump:  xpsr:  0x00000000
00> [00:00:17.384,307] <err> os: esf_dump: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
00> [00:00:17.385,314] <err> os: esf_dump: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
00> [00:00:17.386,322] <err> os: esf_dump: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
00> [00:00:17.387,329] <err> os: esf_dump: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
00> [00:00:17.388,336] <err> os: esf_dump: fpscr:  0x00000000
00> [00:00:17.388,916] <err> os: esf_dump: Faulting instruction address (r15/pc): 0x00000000
00> [00:00:17.389,617] <err> os: z_fatal_error: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:17.390,380] <err> os: z_fatal_error: Current thread: 0x20003ea0 (unknown)
00> [00:00:17.396,118] <err> fatal_error: k_sys_fatal_error_handler: Resetting system

[RossJ]

I'm afraid your moving outside my area of experience as I have only worked with the nRF9160. Has your program ever run with ncs 2.3.0? Or is this error simply the result of fixing one problem and exposing the next? I'm guessing this isn't related to UART anymore. If not already done, you should ensure the UART is ready (i.e. device_is_ready(bms_uart) is true. This also tests for non-null).

I'd probably start running this in the debugger and trying to locate the module/thread which triggers the error. While I only have limited experience interpreting error logs such as the one you've posted, I am suspicious of the 'faulting instruction address' being zero. I have seen something like this when an attempt to dereference a null function pointer is attempted. Could also be caused by memory corruption of a function pointer.

[Sachin Rawat]

RossJ said:

Has your program ever run with ncs 2.3.0? Or is this error simply the result of fixing one problem and exposing the next?

I was working with ncs 1.9.1 till yesterday, having same config for uart and same as device_gets_binding.

And I faced no problem communication with UART, getting data from it and all.

But today I switched to ncs2.3.0 which is having pinctrl added and the device_gets_binding is also not working.

Please help me in resolving this device pointer issue for UART

[RossJ]

Hi Sachin,

I only started with NCS 2.2.0, so really don't know enough to help you on migrating from NCS 1.9.1. I'd imagine given it's major version change (1.x to 2.x) that there are incompatibilities requiring source code changes (more than just pinctrl). Maybe there is a migration or revision information document somewhere on Nordic's website which highlights the key changes to consider. Searching this forum I see you're not the first to be doing such a migration.

If you are unable to find an answer to the problem you are currently experiencing, then perhaps best to wait for a Nordic Semi engineer (I'm just a customer like you) to review this post.

Good luck!

/Ross