• State Not Answered
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 336 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 323918
Options

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

  • 0

    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 

  • 0 in reply to Amanda Hsieh

    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

  • 0 in reply to runqi

    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.

  • 0 in reply to Amanda Hsieh

    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

  • 0 in reply to runqi

    Hi, 

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

    -Amanda H.

Related