SC589-MINI issues error at programming the flash.

There is an alternate to the original bare metal framework available vis github: github.com/.../sam-audio-starter

and a start of the documentation at:  https://wiki.analog.com/resources/tools-software/sharc-audio-module/advanced-audio-projects

The flash driver should be the same one as used for the rev 1.5 boards (older versions may have a different flash device).  The rev 2.1 board was created to address component shortages with building the rev 1.5 boards.  The clock generator chip was replaced with discrete oscillators, there is a different USB UART device,  and there is also a different Ethernet PHY.  The sam-audio-starter project runs on both boards and is a good test.

There is a bootloader included and in the prebuilt folder: https://github.com/analogdevicesinc/sam-audio-starter/tree/1.0.0-Github/bootloader/prebuilt

the bootloader consists of 2 ldr files - once those 2 loader files are programmed in, then it is possible to reflash the board via a USB cable connected to the OTG port and using the "SAM Flasher" utility. (see instructions on the wiki). 

This has been tested with a newer version of CCES - it might be worth also installing the latest version of CCES (it will co-exist with your older version).

Thanks for your reply. I have made a CCES (2.11.1) project: SAM-Audio-Starter and did the steps from Advanced Audio Projects: Set up pre-requisites, then Set up environment and compile, all without problems. Then Flash the bootloader and application, but execution of "./boot0_hw_rev_1_5_cldp.bat" shows the message "Error: failed erasing affected sectors". An ICE1000 has been used and I have modified the .bat scripts (-emu 2000 to -emu 1000). What could be the cause?

Thank you for your help.

Yes, I have written that app; it is not from ADI. The last version (_6) was based on the Baremetal framework.

I only see a window Debug Configurations (Screen1). When the Debug button is clicked, the four programs are loaded (Screen2, console view). All windows are empty,  I do not see a run button or any code or whatsoever.  I am sorry, I have tried to upload the screenshots using Insert > Image/video/file, but did not succeed.

Hi emi.rein  would you be ok switching over to email? I think we can come to a resolution quicker and can easily share screen shots, etc. there. 

Hi Rebecca, good idea, I am ok.  r.vander.welle@freeler.nl

Hi there, was there ever a resolution to this issue?  I have the feeling that what I have run into, the PLL not locking, could cause some the symptoms you have dealt with, though I was able to get the SAM audio starter project working fine.  My question is here, for reference:  ez.analog.com/.../sc589-mini-adau1761-initialization-sampling-set-pll

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. 

HI Rebecca - Thanks for the quick response.  Yes, this issue is in regards to using the SHARC bare metal framework release 2.1.2.  The required update makes perfect sense to me.  I look forward to seeing the posted workaround and update.  I might add that the PLL initialization seems fine in the alternate "simple" framework used with the SHARC audio starter project.  Best regards, Chris

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: 

    if (sample_rate == 48000) {
        r = 2; /** @note: changed by BH. was 4 **/
    }

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

    /** @Note: Added by BH **/
    adau_write_ctrl_reg(adau1761, ADAU1761_REG_DSP_ENABLE, 0x1);
    adau_write_ctrl_reg(adau1761, ADAU1761_REG_DSP_RUN, 0x1);

    return true;
}

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. 

Hi BrandonH, 

Thanks for the very detailed response and this explanation looks sensible.  I will try this workaround ASAP, and let you know if the PLL issue I ran into (and my concerns with the ADAU1761) is resolved.  

Chris

Hi BrandonH, 

The workaround for the MCLK changes in ADAU1761 did solve this particular issue I was experiencing.  The following register read back now works without hanging:

// 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");
}

Further down the line, it seems that the audio processing callback is not operable.  I have another issue cited for that problem:

 SC589 SHARC Bare Metal Framework DMA Enablement - Not Working 

To echo cgchris's findings / concern below,  the audio processing callback is never called and the SHARC cores' utilization stays at 0%.

I also observe that LEDs 10 and 11 never blink.

Thank you,

Chris

Hi BrandonH, 

The workaround for the MCLK changes in ADAU1761 did solve this particular issue I was experiencing.  The following register read back now works without hanging:

// 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");
}

Further down the line, it seems that the audio processing callback is not operable.  I have another issue cited for that problem:

 SC589 SHARC Bare Metal Framework DMA Enablement - Not Working 

To echo cgchris's findings / concern below,  the audio processing callback is never called and the SHARC cores' utilization stays at 0%.

I also observe that LEDs 10 and 11 never blink.

Thank you,

Chris