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]

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?

[denis]

You need to run main...

[Simon]

Ah.. Of course. For some reason I thought it happened during the initialization that runs before main (I've handled many cases lately where this is the case :P. My bad.