Error in configuring UART pins in SDK2.3.0

[sachin]

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]

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]

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]

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.

[RossJ]

I just took a look back through this discussion to see how we got here... Two things stand out to me. First, there is no obvious connection between the UART and BT except that you started investigating a UART problem and changing the UART code triggered the issue in BT. Second, your original crash looked like a dereference of a null function pointer which jumped to address zero. It wasn't until you added the config to disable compile time optimisation, that the fault became the stack overflow (and related to BT).

This all feels to me like some part of your application is causing memory corruption which can lead to a valid pointer being overwritten with zero or a stack getting corrupted (and being reported as an overflow). Whenever you make a significant enough change to the program, the nature of the fault changes. This is consistent with changes in memory allocation etc.

I'm not certain how Zephyr is detecting stack overflow. It could be periodically looking at markers placed at the end of the stack. Note that this check would be periodic, so might not detect the overflow at the exact time it's being caused. If you take a look at the whole memory area allocated to the BT TX stack, watch for changes which are inconsistent with the normal progression of the stack (esp. near the end). It appears you already have CONFIG_INIT_STACKS=y so the stack should be filled with 0xaa, making it relatively simple to look for corruption beyond the used portion of the memory. If you can identify something which is being corrupted, you could try breaking on writes to that location(s).

Another option is to return to the original error of jumping to zero. But you'd have to determine which function pointer is being corrupted. That might be more difficult.

[sachin]

Hi thanks for all the answers RossJ Menon 
I resolved the issue at last 

There are some of the CONFIG that you need to add in your samples prj.conf

CONFIG_UART_INTERRUPT_DRIVEN=n

CONFIG_UART_0_ASYNC=y

CONFIG_UART_0_INTERRUPT_DRIVEN=n

CONFIG_NRFX_UARTE0=y

# Enable the UART driver

CONFIG_UART_ASYNC_API=y

CONFIG_NRFX_UARTE0=y

CONFIG_SERIAL=y

CONFIG_CONSOLE=y

CONFIG_UART_CONSOLE=y


Add these Config and this will resolve this error.