LED Color Anomalies and Suspected Gateway Encoder Initialization Issue with nrf5340

[runqi]

Hello,

I’d like to detail an ongoing issue with LED color states on our hardware setup, along with a potential gateway encoder initialization problem. Ordinarily, the expected behavior is for the gateway center RGB to show green, the left headset to be blue, and the right headset to be purple. After writing to the board, the gateway and one of the headsets switch their LEDs to red after initially showing the correct colors for a short time.

When I reset the headset that switches to red, both headsets return to their proper blue and purple colors, but the gateway continues to show red. Moreover, when I press the reset on the gateway, it momentarily displays the correct green color before reverting to red again. This action also causes one of the headsets to change its LED to red.

Could this be an issue with the encoder initialization on the gateway? If so, what steps can be taken to diagnose and resolve this initialization error?

I appreciate any assistance or insight you can provide on this matter.

Best regards,

Runqi

[Amanda Hsieh]

Hi, 

Are you using nRF53 Audio DK or a custom board?

Which version of NCS are you using?

Could this be an issue with the encoder initialization on the gateway? If so, what steps can be taken to diagnose and resolve this initialization error?

Solid red (debug mode) means a Fault in the application core has occurred. See the UART log for details and use the RESET button to reset the device. In the release mode, the device resets automatically with no indication on LED or UART.

Are you using the nRF5340 Audio application? If so, did you modify it? Please kindly elaborate on the modification.

Could you provide the log from the gateway?

Moreover, when I press the reset on the gateway, it momentarily displays the correct green color before reverting to red again. This action also causes one of the headsets to change its LED to red.

Could you also provide the log file from the headset regarding this part?

Regards,
Amanda Hsieh 

[runqi]

Hi Amanda,

Apologies for the delayed response; I've been diligently troubleshooting some issues in my code throughout this week. Thank you for your patience and for the assistance provided. Regarding your questions, I have the following updates:

1. I am using the nRF53 Audio DK with NCS version v2.5.1.
2. Regarding the issue of the LED lighting up red, I identified and fixed an error last week. However, the gateway board continuously lights up red now, but it seems not to affect the headsets' functionality.
3. Yes, I have been using the nRF5340 audio application and have made some modifications to it.

I have used the nRF Connect Serial Terminal app to track information from the gateway board, and here is what I found:

*** Booting nRF Connect SDK v2.5.1 ***
GW [00:00:00.008,789] <inf> fw_info: 
         nRF5340 Audio nRF5340 Audio DK cpuapp                      
         NCS base version: 2.5.1                            
         Cmake run : Fri Mar 22 15:00:50 2024
GW [00:00:00.008,819] <inf> fw_info: ------- DEBUG BUILD -------
GW [00:00:00.008,819] <inf> fw_info: Compiled for GATEWAY device
GW [00:00:00.019,439] <inf> board_version: Compatible board/HW version found: 1.0.0
GW [00:00:00.066,619] <inf> bt_mgmt_ctlr_cfg: Controller: LL_ACS_NRF53. Version: 3424
GW [00:00:00.068,511] <inf> bt_mgmt: Local identity addr: F9:7D:1C:43:49:F7 (random)
GW [00:00:00.190,917] <inf> bt_mgmt_scan: Local addr: 78:28:AB:58:D8:C8 (random). May time out. Updates not printed
GW [00:00:00.190,917] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:00.792,510] <inf> bt_mgmt_scan: Creating connection to device: 79:1F:DA:21:37:28 (random)
GW [00:00:00.894,104] <inf> bt_mgmt: Connected: 79:1F:DA:21:37:28 (random)
GW [00:00:00.907,043] <inf> bt_mgmt_scan: Local addr: 4F:C9:D0:A1:20:5B (random). May time out. Updates not printed
GW [00:00:00.907,043] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:00.907,287] <inf> streamctrl_unicast_client: Device connected
GW [00:00:01.201,049] <inf> bt_mgmt_scan: Creating connection to device: 65:98:54:7D:A7:AE (random)
GW [00:00:01.297,180] <inf> bt_mgmt: Connected: 65:98:54:7D:A7:AE (random)
GW [00:00:01.297,424] <inf> streamctrl_unicast_client: Device connected
GW [00:00:01.403,381] <inf> streamctrl_unicast_client: Security changed
GW [00:00:01.823,425] <inf> streamctrl_unicast_client: Security changed
GW [00:00:01.923,248] <inf> bt_rend_vol: VCS discover finished
GW [00:00:02.183,258] <inf> bt_rend_vol: VCS discover finished
GW [00:00:03.164,184] <inf> unicast_client: LEFT sink stream configured
GW [00:00:03.243,743] <inf> unicast_client: Enable stream 0x20006bb8
GW [00:00:03.424,224] <inf> unicast_client: RIGHT sink stream configured
GW [00:00:03.503,723] <inf> unicast_client: Enable stream 0x20006e28
GW [00:00:03.683,227] <inf> unicast_client: Stream 0x20006bb8 started
GW [00:00:03.683,502] <err> os: ***** USAGE FAULT *****
GW [00:00:03.683,532] <err> os:   Stack overflow (context area not valid)
GW [00:00:03.683,532] <err> os: r0/a1:  0x20021648  r1/a2:  0x2001430c  r2/a3:  0x00000001
GW [00:00:03.683,532] <err> os: r3/a4:  0x00000064 r12/ip:  0x00000064 r14/lr:  0x00049d39
GW [00:00:03.683,563] <err> os:  xpsr:  0x81000000
GW [00:00:03.683,563] <err> os: s[ 0]:  0x00000002  s[ 1]:  0x00000002  s[ 2]:  0x00003e80  s[ 3]:  0x00000064
GW [00:00:03.683,593] <err> os: s[ 4]:  0x20014288  s[ 5]:  0x00049d39  s[ 6]:  0x00000000  s[ 7]:  0x00000001
GW [00:00:03.683,593] <err> os: s[ 8]:  0x20014288  s[ 9]:  0x00000fb8  s[10]:  0x200059d4  s[11]:  0x00000fb0
GW [00:00:03.683,593] <err> os: s[12]:  0x00000fb0  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x20014280
GW [00:00:03.683,593] <err> os: fpscr:  0x00000000
GW [00:00:03.683,624] <err> os: Faulting instruction address (r15/pc): 0x00049a18
GW [00:00:03.683,624] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
GW [00:00:03.683,654] <err> os: Current thread: 0x20006998 (LE_AUDIO_MSG_SUB)
GW [00:00:03.683,654] <err> error_handler: Caught system error -- reason 2. Entering infinite loop

Additionally, I was wondering if you could guide me on how to view the printf messages from the code running on the board in the terminal. Understanding how to correctly see these messages would greatly help me in debugging and further refining the application.

Thank you once again for your help and support.

Runqi

[Amanda Hsieh]

Hi, 

The log indicated "Stack overflow" due to " Current thread: 0x20006998 (LE_AUDIO_MSG_SUB)". Could you try to increase the value of  CONFIG_LE_AUDIO_MSG_SUB_STACK_SIZE?

-Amanda H.

[runqi]

Hi Amanda,

I wanted to update you on the significant progress we've made following your guidance. After our last conversation, I took a two-pronged approach to address the issues we identified:

1. For the LE_AUDIO_MSG_SUB thread, I increased the stack size to 512000, substantially more than the initial adjustment, to ensure ample space for its operations.
2. For the ENCODER thread, I also doubled the original stack size, in line with your advice, to better accommodate its requirements.

These adjustments have led to notable improvements: the gateway now displays a green light, with LED1 blinking blue and LED3 blinking green, indicating normal operation. Additionally, both headsets are showing blinking green lights on LED3, which I take as a positive sign of their correct functioning. Here are the details of the log reflecting these changes:

*** Booting nRF Connect SDK v2.5.1 ***
GW [00:00:00.008,758] <inf> fw_info: 
         nRF5340 Audio nRF5340 Audio DK cpuapp                      
         NCS base version: 2.5.1                            
         Cmake run : Tue Mar 26 11:38:25 2024
GW [00:00:00.008,789] <inf> fw_info: ------- DEBUG BUILD -------
GW [00:00:00.008,789] <inf> fw_info: Compiled for GATEWAY device
GW [00:00:00.019,409] <inf> board_version: Compatible board/HW version found: 1.0.0
GW [00:00:00.066,558] <inf> bt_mgmt_ctlr_cfg: Controller: LL_ACS_NRF53. Version: 3424
GW [00:00:00.068,450] <inf> bt_mgmt: Local identity addr: E0:EC:65:33:21:B2 (random)
GW [00:00:00.191,223] <inf> bt_mgmt_scan: Local addr: 5C:25:B8:F1:FB:30 (random). May time out. Updates not printed
GW [00:00:00.191,253] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:00.786,499] <inf> bt_mgmt_scan: Creating connection to device: 46:DD:F3:E7:E6:C9 (random)
GW [00:00:00.880,584] <inf> bt_mgmt: Connected: 46:DD:F3:E7:E6:C9 (random)
GW [00:00:00.884,796] <inf> bt_mgmt_scan: Local addr: 53:63:C3:4F:99:FA (random). May time out. Updates not printed
GW [00:00:00.884,796] <inf> bt_mgmt_scan: Scanning successfully started
GW [00:00:00.885,040] <inf> streamctrl_unicast_client: Device connected
GW [00:00:01.181,610] <inf> bt_mgmt_scan: Creating connection to device: 6C:3B:E1:5F:72:C3 (random)
GW [00:00:01.277,282] <inf> bt_mgmt: Connected: 6C:3B:E1:5F:72:C3 (random)
GW [00:00:01.277,526] <inf> streamctrl_unicast_client: Device connected
GW [00:00:01.403,350] <inf> streamctrl_unicast_client: Security changed
GW [00:00:01.823,394] <inf> streamctrl_unicast_client: Security changed
GW [00:00:01.843,200] <inf> bt_rend_vol: VCS discover finished
GW [00:00:02.223,236] <inf> bt_rend_vol: VCS discover finished
GW [00:00:03.124,176] <inf> unicast_client: LEFT sink stream configured
GW [00:00:03.203,704] <inf> unicast_client: Enable stream 0x20006bb8
GW [00:00:03.643,188] <inf> unicast_client: Stream 0x20006bb8 started
GW [00:00:03.664,154] <inf> unicast_client: RIGHT sink stream configured
GW [00:00:03.669,891] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.669,891] <wrn> streamctrl_unicast_client: Problem with sending LE audio data, ret: -22
GW [00:00:03.678,894] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.689,544] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.698,974] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.708,923] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.719,665] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.729,400] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.738,952] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.743,713] <inf> unicast_client: Enable stream 0x20006e28
GW [00:00:03.749,877] <err> unicast_client: The encoded data size does not match the SDU size
GW [00:00:03.759,613] <err> unicast_client: The encoded data size does not match the SDU size
--- 1 messages dropped ---
GW [00:00:03.809,539] <err> unicast_client: The encoded data size does not match the SDU size
--- 7 messages dropped ---
GW [00:00:03.869,567] <err> unicast_client: The encoded data size does not match the SDU size
--- 5 messages dropped ---
GW [00:00:03.929,351] <err> unicast_client: The encoded dataFailed to allocate scratch memory!
exit

These errors suggest that the encoded data size does not match the expected SDU size, and there was also a failure to allocate scratch memory. Given these issues seem related to data handling rather than stack size, could you advise on potential causes or solutions? Specifically, are there configuration parameters or resource allocations that I should review or adjust to address these discrepancies and memory allocation issues?

Thank you once again for your support. I'm looking forward to resolving these new challenges and moving forward with the development.

Best regards,

Runqi

[Amanda Hsieh]

Hi, 

The team suggests to use NCS v2.6.0 which is more stable. Could you try v2.6.0?

-Amanda H.

[runqi]

Hi Amanda,

Thank you for the suggestion. I will definitely try switching to NCS v2.6.0 to see if it offers more stability for my project.

Regarding the version switch, I've checked my system with nrfutil toolchain-manager search and found that I currently have versions 2.5.1 and 2.5.2 installed. Once I install v2.6.0, could you guide me on how to switch to this new version for my project? I want to ensure I’m utilizing v2.6.0 correctly without affecting the existing setup.

Additionally, I have another question related to the debugging of my application. How can I determine and print the SDU size and the payload size for LC3 within my code? Understanding these values in real-time could greatly help me in troubleshooting and optimizing the data handling process.

Thank you again for your support and guidance. I’m looking forward to your advice on these matters.

Best regards,

Runqi

[Amanda Hsieh]

Hi, 

runqi said:

could you guide me on how to switch to this new version for my project?

See the v2.6.0 migration guide for nRF5340 Audio applications. Duplicate the v2.6.0 Audio application, and modify it as you did on v2.5.1.  

runqi said:

How can I determine and print the SDU size and the payload size for LC3 within my code? Understanding these values in real-time could greatly help me in troubleshooting and optimizing the data handling process.

v2.6.0 might solve this issue. 

-Amanda H.