• State Verified Answer
  • Replies 6 replies
  • Subscribers 73 subscribers
  • Views 991 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 314895
Options

nrf5340 audio: How to remove dependence on 32k oscillator

Reskyllr

We have a custom development board based on 5340 audio, and based on cost control, we want to remove the 32k oscillator.
But after removing it, the program cannot run normally. Is there any dependence on it in the nrf5340 audio demo? How should I remove it?

Parents Reply Children
  • 0 in reply to dejans

    Hi, Dejan

    Yes, I want to tear them down.

    The current location is that when the external flash memory DFU function is started, the program cannot run (it should be that MCUBoot is waiting for the crystal oscillator device).
    But I don't know how to modify it, currently I added the following configuration to disable them.
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

    Thanks,

    Reskyllr

  • 0 in reply to dejans

    Hi, there is new progress,
    I try to add the following config under mcuboot:
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
    CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
    The log begins to output, but the network core BLE cannot be enabled.
    On the development board with a crystal oscillator, it works normally, with the same hex.

    HL [00:00:00.201,385] <inf> fw_info: 
   nRF5340 Audio nRF5340 Audio DK cpuapp           
   NCS base version: 2.4.0           
   Cmake run : Tue Sep 26 14:55:50 2023
HL [00:00:00.201,385] <inf> fw_info: ------- DEBUG BUILD -------
HL [00:00:00.201,385] <inf> fw_info: HEADSET left device
HL [00:00:00.701,446] <err> ble: No response from NET core, check if NET core is programmed
HL [00:00:00.701,446] <err> ble: ERR_CHK Err_code: [-5] @ line: 43  
HL [00:00:00.701,477] <err> os: r0/a1:  0x00000003  r1/a2:  0x00000002  r2/a3:  0x00000001
HL [00:00:00.701,477] <err> os: r3/a4:  0x00090a0f r12/ip:  0x00000010 r14/lr:  0x00090a99
HL [00:00:00.701,477] <err> os:  xpsr:  0x41000025
HL [00:00:00.701,507] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
HL [00:00:00.701,507] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
HL [00:00:00.701,538] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
HL [00:00:00.701,538] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
HL [00:00:00.701,568] <err> os: fpscr:  0x00000000
HL [00:00:00.701,568] <err> os: Faulting instruction address (r15/pc): 0x0001590a
HL [00:00:00.701,599] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
HL [00:00:00.701,599] <err> os: Fault during interrupt handling

HL [00:00:00.701,629] <err> os: Current thread: 0x20005658 (idle)
HL [00:00:00.701,660] <err> error_handler: Caught system error -- reason 3. Entering infinite loop

  • +1 in reply to Reskyllr

    Hi,

    You could try adding configuration options which specify that LFCLK will not be taken from 32.768 KHz crystal. Instead, it will be synthesized from 32 MHz clock.

    CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=y


    Best regards,
    Dejan

  • 0 in reply to dejans

    Hi,

    I added this to the subimage,work well.

    Thanks,

    Reskyllr

  • 0 in reply to Reskyllr

    Hi,

    Thank you for the update. This is great to know.

    Best regards,
    Dejan

Related
Terms of service