SC589 mini ADAU1761 initialization / sampling set / PLL

I have exactly the same problem. Can someone help?

This may help a bit, fairly soon. See this question:  ez.analog.com/.../504290

"Hi chlander73 , 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:

drivers/bm_adau_driver/configurations/ss_schematics/ADAU1761_ADAU1761_8ch_i2s_master/Exported_init_files/NumBytes_ADAU1761.dat

drivers/bm_adau_driver/configurations/ss_schematics/ADAU1761_ADAU1761_8ch_i2s_master/Exported_init_files/TxBuffer_ADAU1761.dat

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 chlander73 , 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. 

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 (analog.com). 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.