Post Go back to editing

SC589 mini ADAU1761 initialization / sampling set / PLL

Category: Software
Product Number: ADZS-SC589-mini Rev. 2.1
Software Version: SHARC Bare Metal Framework 2.1.2 / Cross Core Embedded 2.11.1

Basic setup:  ADZS SC589 mini Board Rev. 2.1, Cross Core Embedded 2.11.1 SHARC bare Metal Framework template project, without the Audio Project Fin setting, no FAUST, and SHARC core 1 in use only.

The audio block size is 32, the sample rate is 48kHz.  The project has been run in a Debug configuration using the ICE 1000 emulator.

Problem:  The audio framework does not successfully initialize due to the ADAU 1761 codec not initializing correctly (as far as I can tell).

During the ARM core startup process, and audio framework initialization, the ADAU1761 codec is initialized.  The function in question is:

bool adau1761_set_samplerate(BM_ADAU_DEVICE *adau1761,
uint32_t sample_rate)

This function implementation is in the bm_adau_driver.c source file.

The specific block of code (below) is where the PLL is set and verified.  The while loop used to find the PLL locked bit goes into an infinite loop, and the entire program

obviously hangs.

// 3. wait for PLL to lock
uint8_t addr[2], result[6], value = 0;
addr[0] = ADAU1761_REG_PLL_CONTROL_0 >> 8;
addr[1] = ADAU1761_REG_PLL_CONTROL_0 & 0xff;

while ((value & 0x2) == 0) {
twi_write_block_r(&adau1761->twi, addr, 2, true);
twi_read_block(&adau1761->twi, result, 6);
value = result[5];
}

Question:  Why doesn't the PLL lock?  I have successfully run the SAM audio starter, and the ADAU1761 codec seems to work fine.  I am just not sure where the template SHARC bare metal framework is

missing some configuration files or if there is something wrong in the project setup.  The logging is fine, and I have been able to pinpoint this area of code as an issue.  I have thought about using the SAM audio starter project as a model for getting this to work, but I

was hoping that someone had a quick fix. 

Any help would be appreciated!

Regards,

Chris



Type errors
[edited by: chlander73 at 6:48 PM (GMT -4) on 9 Sep 2023]
Parents
  • This is the workaround carried over from the flash issue (below).

    The basic idea is that the new ADAU1761 codec part needs double the clock rate, without some other initialization, so the workaround provided was to change the clock divisor from r= 4 to r = 2. in the set_samplerate function of the adau1761 driver.  This did fix the ADAU1761 PLL initialization and sample rate setting, and the ADAU1761 can be verified to be running per ADI's api's.

    (The DMA enable question/ issue has a new, separate thread:   SC589 SHARC Bare Metal Framework DMA Enablement - Not Working)

    /// Start of workaround

    Hi  , here is the workaround for the SC589-MINI 2.1 PLL issue:

    The MCLK for ADAU1761 on the 2.0+ HW is actually 1/2 the MCLK on previous hardware iterations. So there are a couple small tweaks to be made to the driver...in particular head to src/drivers/bm_adau_driver/bm_adau_driver.c:

    • In the adau1761_set_samplerate function, set the value of "r" to 2 under the 48000 Hz option. This is currently hard-coded to 4, which is not an appropriate value for SC589-MINI 2.0+ hardware: 

    • At the end of this function, add the following two lines to ensure the DSP ENABLE and DSP RUN bits are set before the checks are done for these bits clearing. This is done in the .dat file by standard, but this was something I put in just to be sure it was happening:

    This should be all that is needed to solve the PLL locking issues on SC589-MINI v2.0+. I just tested on 2.1 HW to verify as well. Feel free to let us know if this does not solve your issue. 

Reply
  • This is the workaround carried over from the flash issue (below).

    The basic idea is that the new ADAU1761 codec part needs double the clock rate, without some other initialization, so the workaround provided was to change the clock divisor from r= 4 to r = 2. in the set_samplerate function of the adau1761 driver.  This did fix the ADAU1761 PLL initialization and sample rate setting, and the ADAU1761 can be verified to be running per ADI's api's.

    (The DMA enable question/ issue has a new, separate thread:   SC589 SHARC Bare Metal Framework DMA Enablement - Not Working)

    /// Start of workaround

    Hi  , here is the workaround for the SC589-MINI 2.1 PLL issue:

    The MCLK for ADAU1761 on the 2.0+ HW is actually 1/2 the MCLK on previous hardware iterations. So there are a couple small tweaks to be made to the driver...in particular head to src/drivers/bm_adau_driver/bm_adau_driver.c:

    • In the adau1761_set_samplerate function, set the value of "r" to 2 under the 48000 Hz option. This is currently hard-coded to 4, which is not an appropriate value for SC589-MINI 2.0+ hardware: 

    • At the end of this function, add the following two lines to ensure the DSP ENABLE and DSP RUN bits are set before the checks are done for these bits clearing. This is done in the .dat file by standard, but this was something I put in just to be sure it was happening:

    This should be all that is needed to solve the PLL locking issues on SC589-MINI v2.0+. I just tested on 2.1 HW to verify as well. Feel free to let us know if this does not solve your issue. 

Children