• State Not Answered
  • Replies 7 replies
  • Subscribers 25 subscribers
  • Views 242 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290129
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

Problems with nrf5340 audio example

user107450

When I use two nrf5340 audio DK to test the LE audio demo, the handset side always crashes. Especially when I move the DK that is used as the handset.I think that incomplete data reception due to compromised communication can cause a crash problem.

Configuration:

CONFIG_SW_CODEC_SBC=y

Logs:

HL [00:01:39.629,425] <wrn> sw_codec_select: PCM samples dropped
HL [00:01:39.629,425] <err> audio_datapath: Decoded audio has wrong size
HL [00:01:39.629,455] <err> audio_datapath: ERR_CHK Err_code: [-140] @ line: 833
HL [00:01:39.6os: r0/a1:  0x00000003  r1/a2:  0x00000006  r2/a3:  0x00000005
 [00:01:39.629,455] <err> os:  xpsr:  0x41000000d0 r12/ip:  0x00000002 r14/lr:  0x000177ed
HL [00:01:39.629,455] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
HL [00:01:39.629,486] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
HL [029,486] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
HL [00:01:39.629,486] <err> os: s[12]:  0x00000000  s[13]:  0xffffffff  s[14]:  0x00000000  s[15]:  0x00000000
HL [00:01:39.629,516] <err> os: fpscr:  0xffffffff
HL [00:01:39.629,516] <err> os: Faulting instruction address (r15/pc): 0x00006104
HL [00:01:39.629,516] R FATAL ERROR 3: Kernel oops on CPU 0
HL [00:01:39.629,547] <err> os: Current thread: 0x20001648 (AUDIO DATAPATH)
HL [00:01:39.629,547] <err> error_handler: Caught system error -- reason 3. Entering infinite loop

And when use ''CONFIG_TRANSPORT_BIS=y'' same as above.

  • 0 in reply to user107450

    Thank you for providing the diff output and the full log, I will discuss this with some colleagues internally and get back to you as soon as I have an update.

    Best regards,
    Karl

  • 0 in reply to user87869

    Hello again,

    I've discussed this with some colleagues now and the behavior shown in your log is something we have seen before when using the SBC codec. In essence, it is caused by sw_codec_select not handling the SBC's output properly when a bad frame occurs.
    As a quick fix for this I suggest that you just remove the ERR_CHK_MSG on line 815 in this case - at worst this could sometimes produces audiable artifacts when a bad frame occurs with the SBC codec, since ctrl_blk.decoded_data contains the data from the last frame/package, which means that the same frame will be played twice. It is not ideal fix, but it is better than the device resetting at least, for the time being.

    Please try this, and let me know if it resolves the issue.

    Best regards,
    Karl

Related
Terms of service