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

[Menon]

Hello Sachin,

I am pretty sure it is not a UART issue. There are some limitations for us with debugging every kind of C problem. But for debugging the Stack overflow I recommend you to include the below configurations and find the proper cause of crashing.

CONFIG_NO_OPTIMIZATIONS=y

 

CONFIG_THREAD_NAME=y

CONFIG_THREAD_ANALYZER=y

CONFIG_THREAD_STACK_INFO=y

CONFIG_THREAD_MONITOR=y

CONFIG_THREAD_ANALYZER_ISR_STACK_USAGE=y

CONFIG_THREAD_ANALYZER_AUTO_INTERVAL=5

# CONFIG_THREAD_ANALYZER_USE_PRINTK=n

CONFIG_THREAD_ANALYZER_AUTO=y

CONFIG_THREAD_ANALYZER_USE_LOG=y

CONFIG_THREAD_ANALYZER_AUTO_STACK_SIZE=65536

 

CONFIG_INIT_STACKS=y

CONFIG_STACK_USAGE=y

CONFIG_STACK_SENTINEL=y

Kind Regards,

Abhijith

[Sachin Rawat]

Hi Menon 

I have used these configs to check the stack overflow, but I found none.

I have tried so many different approaches to changing the stack size but nothing works.

In the thread analyser, I don't find any thread taking excessive buffers. 

The stack overflow is when the bt_enable() function is called and especially in BT_TX. <<---- Already explain in my last reply
I request Menon and other members of Nordic to help me with this approach.

[RossJ]

Hi Sachin,

I just noticed that while you appear to be getting a stack overflow on the BT TX thread, I don't see a config to set the stack size in your list posted on 24/5 ("Here is what my prj.conf is having the stack sizes"). You set the RX stack size and numerous buffers etc., but not the actual TX stack size.

I have no experience working with BT (only LTE), so can't really tell you which CONFIG is the correct parameter to set. This might be worth you looking into.

Regards, Ross

[Sachin Rawat]

Hi RossJ 
I tried that also, I have changed the 

CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y

CONFIG_BT_HCI_TX_STACK_SIZE=8192

But nothing works.

[RossJ]

It was just a thought. I assume you've checked to make sure the config settings are being successfully applied? i.e. by checking the build/zephyr/.config file. Also that the new stack size is actually being applied to the BT TX thread where the error is occurring, using the debugger?
If significantly increasing the stack size still results in a stack overflow, you might need to consider some kind of recursive loop. Have you followed through the code execution on this thread in the debugger? Look at the call stack to see if there is a repeating pattern which might support a recursive loop theory. 

[Sachin Rawat]

RossJ said:

I assume you've checked to make sure the config settings are being successfully applied?

Yes, I verified it.

RossJ said:

Also that the new stack size is actually being applied to the BT TX thread where the error is occurring, using the debugger?

Yup, also verified.

RossJ said:

Have you followed through the code execution on this thread in the debugger?

Yup, the debugger moves in the bt_enable() --> bt_init(); --> hci_init(); --> common_init() --> bt_hci_cmd_send_sync(BT_HCI_OP_RESET, NULL, &rsp)

And this belongs to Zephyr libraries.

When I am adding the line bms_uart = DEVICE_DT_GET(DT_NODELABEL(uart2));
Then there is a stack overflow error in the above path of Bluetooth libraries, otherwise, it is good to go.