NCS USB CDC fault when CONFIG_NO_OPTIMIZATIONS=y

[denis]

When using USB with CONFIG_NO_OPTIMIZATIONS=y I'm getting a usage fault and Zephyr gives the reason K_ERR_STACK_CHK_FAIL.  The fault looks like it occurs in the unnamed thread created near the bottom of usb_dc_nrfx.c.

If CONFIG_NO_OPTIMIZATIONS=n then I do not see the hard faults.

I previously reported this same issue and changing the stack size to 4096 seemed to resolve it then.  However, even if I increase the stack size to 8192 now I'm still seeing the fault.

CONFIG_NO_OPTIMIZATIONS=y

CONFIG_EXTRA_EXCEPTION_INFO=y

CONFIG_RESET_ON_FATAL_ERROR=n

CONFIG_MAIN_STACK_SIZE=8192

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192

CONFIG_USB=y

CONFIG_USB_DEVICE_PRODUCT="Itamar Loop CDC & MSD"

CONFIG_USB_CDC_ACM=y

CONFIG_USB_WORKQUEUE_STACK_SIZE=8192

CONFIG_USB_NRFX_WORK_QUEUE_STACK_SIZE=8192

 

Any ideas on what might be going on here?

[Simon]

Could you set CONFIG_LOG=Y, CONFIG_RESET_ON_FATAL_ERROR=n and CONFIG_THREAD_NAME=y in the prj.conf and provide the log output?

Could you figure out the exact location the issue happens by following using addr2line and the approach described here:

3.4 Other tips and tools --> hard faults

Take a look at this ticket as well: https://devzone.nordicsemi.com/f/nordic-q-a/81217/generate-useful-stack-usage-report-with-zephyr-nrf-connect/336645#336645 

Best regards,

Simon

[denis]

I used the cdc_acm example on an nRF5340dk and added this to the top of the prj.conf:

CONFIG_NO_OPTIMIZATIONS=y

CONFIG_DEBUG_THREAD_INFO=y

CONFIG_LOG=y

CONFIG_EXTRA_EXCEPTION_INFO=y

CONFIG_RESET_ON_FATAL_ERROR=n

 

The log output is:

*** Booting Zephyr OS build v2.6.99-ncs1 ***
[00:00:08.173,431] <inf> cdc_acm_echo: Wait for DTR
[00:00:08.177,520] <inf> usb_cdc_acm: Device suspended
[00:00:08.510,711] <inf> usb_cdc_acm: Device resumed
[00:00:08.510,742] <inf> usb_cdc_acm: from suspend
[00:00:08.560,577] <err> os: ***** USAGE FAULT *****
[00:00:08.560,577] <err> os: Stack overflow (context area not valid)
[00:00:08.560,607] <err> os: r0/a1: 0xb7020010 r1/a2: 0x200032f8 r2/a3: 0x04371215
[00:00:08.560,607] <err> os: r3/a4: 0x200033f7 r12/ip: 0x03121141 r14/lr: 0x20000078
[00:00:08.560,638] <err> os: xpsr: 0xbfe1b200
[00:00:08.560,638] <err> os: r4/v1: 0x00000000 r5/v2: 0x00000000 r6/v3: 0x00000000
[00:00:08.560,638] <err> os: r7/v4: 0x200032f8 r8/v5: 0x00000000 r9/v6: 0x00000000
[00:00:08.560,668] <err> os: r10/v7: 0x00000000 r11/v8: 0x00000000 psp: 0x200032f0
[00:00:08.560,699] <err> os: EXC_RETURN: 0xfffffffd
[00:00:08.560,729] <err> os: Faulting instruction address (r15/pc): 0x11085477
[00:00:08.560,729] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
[00:00:08.560,760] <err> os: Current thread: 0x20000558 (unknown)
[00:00:08.662,414] <err> os: Halting system

(I assume (unknown) is because the fault looks like it occurs in the unnamed thread created near the bottom of usb_dc_nrfx.c.  I suggest adding a name for that thread to usb_dc_nrfx.c.)

Faults right away every time for me, so maybe you can try to reproduce this there?

I'll see if I can get addr2line on my Mac to get that output also.

[denis]

Some more information:

1) If I increase the stack sizes to 8k then the hard fault goes away.

2) If I then turn off logging (CONFIG_LOG=n) the hard fault comes back.

The above is when using the nrf5340dk.  I'm trying to use USB on my custom board.  On my custom board I do not have a UART available for logging, so I have logging turned off.

Can you try to reproduce with CONFIG_LOG=n and set a breakpoint in the debugger in arch_system_halt?  It seems to be hitting that every time for me right away even with large stack sizes set (8k).

[Simon]

I added CONFIG_LOG=n to the sample <ncs location>/zephyr/samples/subsys/usb/cdc_acm/prj.conf and started a debug session and did not encounter any issues. Did you add anything else? I guess CONFIG_NO_OPTIMIZATIONS as well, but I don't like to assume.

Could you upload the sample (or a diff) and explain step by step how to reproduce the issue?

Best regards,

Simon

[denis]

To reproduce, I copied zephyr/samples/subsys/usb/cdc_acm and change prj.conf as below.  Then I debug in VSCode with a breakpoint in arch_system_halt on an nrf5340dk.  The breakpoint is hit right away after running.  Can you reproduce?

prj.conf:

CONFIG_NO_OPTIMIZATIONS=y
CONFIG_LOG=n

CONFIG_USB_WORKQUEUE_STACK_SIZE=8192
CONFIG_USB_NRFX_WORK_QUEUE_STACK_SIZE=8192
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
CONFIG_MAIN_STACK_SIZE=8192

CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_NAME=y
CONFIG_DEBUG_THREAD_INFO=y

CONFIG_STDOUT_CONSOLE=y
CONFIG_USB=y
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="Zephyr CDC ACM sample"
#CONFIG_LOG=y
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_CDC_ACM=y
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y

[Simon]

• I modified the CDC ACM sample accordingly:

diff --git a/samples/subsys/usb/cdc_acm/prj.conf b/samples/subsys/usb/cdc_acm/prj.conf
index ed11167bd1..56aaad332a 100644
--- a/samples/subsys/usb/cdc_acm/prj.conf
+++ b/samples/subsys/usb/cdc_acm/prj.conf
@@ -1,11 +1,23 @@
+CONFIG_NO_OPTIMIZATIONS=y
+CONFIG_LOG=n
+
+CONFIG_USB_WORKQUEUE_STACK_SIZE=8192
+CONFIG_USB_NRFX_WORK_QUEUE_STACK_SIZE=8192
+CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=8192
+CONFIG_MAIN_STACK_SIZE=8192
+
+CONFIG_RESET_ON_FATAL_ERROR=n
+CONFIG_THREAD_NAME=y
+CONFIG_DEBUG_THREAD_INFO=y
+
 CONFIG_STDOUT_CONSOLE=y
 CONFIG_USB=y
 CONFIG_USB_DEVICE_STACK=y
 CONFIG_USB_DEVICE_PRODUCT="Zephyr CDC ACM sample"
-CONFIG_LOG=y
+#CONFIG_LOG=y
 CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
 CONFIG_USB_CDC_ACM=y
 CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
 CONFIG_SERIAL=y
 CONFIG_UART_INTERRUPT_DRIVEN=y
-CONFIG_UART_LINE_CTRL=y
+CONFIG_UART_LINE_CTRL=y
\ No newline at end of file

• Then I built it using the board nrf5340dk_nrf5340_cpuapp
• I opened an Ozone debug session and set a break point in main.c-->main()

• No faults happened, since it's able to reach the break point

Can you do the exact same and see if you get the same output?