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!



Type errors
[edited by: chlander73 at 6:48 PM (GMT -4) on 9 Sep 2023]
  • I have exactly the same problem. Can someone help?

  • This may help a bit, fairly soon. See this question:

    "Hi  , for the specific issue of booting, we have not gotten to a resolution as we could not reproduce the same. The hardware in question is in transit though and we will continue debugging once we receive it. 

    Regarding your PLL issue, are you having an issue with the baremetal framework? If so, it has not been updated yet to be compatible with the 2.1 hardware but one of our engineers has a workaround for that one. I will have that engineer post that information here."

  • Update:

    After looking over the SAM audio start adau1761 code, i found that there should be a 0-10 second wait for the PLL to lock.  Other sources on the web for Linux implementations recommended the same.  With some additional changes, I was able to get the default SHARC core 1 loopback audio processing working.  The volume is very low, so turn up your input source and the amplifier receiving the output from the SC589 / ADAU1761.  I have yet to mess with the gain settings.

    I modified the while loop as follows:

    uint16_t timeout = 10000;

    log_event(EVENT_INFO, "Attempting PLL lock");

    while (timeout-- && ((value & 0x2) == 0)) {

        twi_read_block(&adau1761->twi, result, 6);
        value = result[5];

    if (timeout == 0) {
        log_event(EVENT_FATAL, "PLL would not lock before 10 sec timeout");
    } else {
       log_event(EVENT_INFO, "PLL lock success!");

    Additionally, I took the exported SigmaAudio parameter files from the SAM audio starter project and replaced those at these paths:



    A verification block of code was an issue, so I commented that out (this is just after the sampling setting / PLL lock).

    // Confirm that the ADAU1761 is running (a good indication that it has been initialized properly)
    //uint8_t sigmadspRunning;
    //adau_read_ctrl_reg(&adau1761_local, ADAU1761_REG_DSP_RUN, &sigmadspRunning);
    //if (!(sigmadspRunning & 0x1)) {
    // log_event(EVENT_FATAL, " The SigmaDSP core inside the ADAU1761 is not running");

    Also, if you are not using the Audio Project Fin, comment out the gain settings:

    // Set the AUX channel gain depending on whether a Audio Project Fin is present, and which version of the board
    //uint8_t currentRegVal;
    // Left channel AUX gain
    //adau_read_ctrl_reg(&adau1761_local, ADAU1761_REG_REC_MIXER_LEFT_1, &currentRegVal);
    //currentRegVal &= 0xF8;
    //currentRegVal |= auxGain;
    //adau_write_ctrl_reg(&adau1761_local, ADAU1761_REG_REC_MIXER_LEFT_1, currentRegVal);

    // Right channel AUX gain
    //adau_read_ctrl_reg(&adau1761_local, ADAU1761_REG_REC_MIXER_RIGHT_1, &currentRegVal);
    //currentRegVal &= 0xF8;
    //currentRegVal |= auxGain;
    //adau_write_ctrl_reg(&adau1761_local, ADAU1761_REG_REC_MIXER_RIGHT_1, currentRegVal);

    Update (9/10):

    The DMA's in the SHARC cores are not enabling.  So, the audio observation was not observed from within audio processing blocks.  This is likely just the codec's own loopback.

    Still working to have the audio processing part work. 

    Update (9/10) - 2:

    DMAs enable with a while / timeout, but audio is still not being processed as expected.  The audio buffers in the processing block do not appear to be connected to anything, where the ADUA1761 is concerned.  I may raise a new question for this specific issue.  Or, it may be that I need to wait on a new framework revision.

  • 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 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. 

  • Hello, I'm reposting to link the additional steps to get the SPORT DMA interfacing with ADAU1761. The solution is posted in this thread here: SC589-MINI issues error at programming the flash. - Q&A - SHARC Audio Module - EngineerZone ( Adding the PLL fix and this other fix should resolve all audio throughput issues with SC589-MINI 2.1 hardware and allow the Baremetal Framework to work properly.