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.

Hi Rebecca. At the outset I have tried to load the.ldr file used with former versions of the MINI board. Loading was tried using the ICE1000 interface. The app-name was "Convolution_6". ggeerling mentioned the differences between the 1.5 and 2.1 boards. Then I switched to GitBash and so on.
The present app names are just the same as in your tutorial: SAM-Audio-Starter.ldr, SAM-Audio-Starter-ARM.exe, SAM-Audio-Starter-SHARC0.dxe, SAM-Audio-Starter-SHARC1.dxe.

Hi Rebecca, I have followed your tutorial on Setting Up a Debug Session in CCES and have run Debug. The software has been properly loaded (four times message "Load complete"), but the LED on the ICE-1000 does not turn back to green. So no running board; no connection with a COM port, and the 'CP22102N USB to UART Bridge Controller port' is shown when the USB/UART port on the board is used.
This first test was with the makefile without the -DUSB_CDC_STDIO flag. I have included that flag again, did make clean and an new build and obtained identical results.

As I have three MINI boards available I have tested the other two with identical results; so no hardware errors, I suppose. A slight difference because the boards are used for the first time, at power up: LED9 and 11 are on, LED10 is blinking, LED7 is on. After loading only LED9 is on; after reset the former situation with LEDS 9, 11, 10 and 7.

Hi emi.rein , when you start a debug session, we don't expect the debugger light to change back to green. It should remain purple for the time that the session is running. After you loaded the ARM DXE, did your debugger halt at main? And if so, after this, did you hit the run button to run the code? Can you share a screenshot of your CCES after you start the debug session please? 

Is the app 'Convolution_6' and application that you wrote? Or is that an application that ADI provided? Do you know if this was based from the Baremetal framework? 

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

thanks for the solution.

With this changes the PLL seems to initialize properly.

Anyway, audio processing is still not working in my setup. According to the terminal output it seems like the dsp core won's start with the corresponding clock frequency.

0.00MHz of 450.00 MHz?

Also the leds 10 and 11 are inactive after the init sequence...

(CCES 2.11.1, SC589-MINI v2.1, 48kHz, 32 Samples, Only Core 1 for audio, No Audio Project Fin)

I tested this with a complete fresh project of the baremetal framework 2.1.2 with just the changes from you post for PLL locking issue.

Any idea what could be still wrong?

Thanks

Chris

Hello,

Apologies for the delay on this -- I was out sick for a week and took some time to get back to this question. It looks like the issue here is 2 things:The SigmaStudio project files had some issues with the register configuration for the ADAU1761 SPORT. The issues were:

1. The SPORT is configured as an I2S slave in register 0x4015, meaning it expects the SHARC to drive BCLK/LRCLK before it sends out any serial data. This is why the DMA interrupts never triggered. 
   1. The LRCLK setting is mismatched between the SHARC SPORT and the ADAU1761 SPORT, making for some channel matching issues over the TDM8 link. 

Exported_init_files.zip

I'm attaching a revised SigmaStudio file you can replace into your Baremetal Framework. It should go at this path: "C:\workspace\cces\2.11.1\sam_bm_project\drivers\bm_adau_driver\configurations\ss_schematics\ADAU1761_ADAU1761_8ch_i2s_master".

2. In the Baremetal Framework, the SRU configuration of the codec signals needs to match the configuration of the ADAU1761. Currently it seems as though there's an issue here where the SRU is initializing it expecting A2B due to a preprocessor typo. I made the following change to the ARM audio framework file:

Once I replaced the SigmaStudio project file and matched it with the proper SRU configuration, the SAM board was able to receive and play audio from LINE IN to LINE OUT:

Let us know if there are any issues replicating this!

OK - great news!  Thanks so much for digging into this.  i will check out the solution ASAP - looks like a winner.  

Edit:  Yes, that all checked out and the audio processing callback works.  Very well done!  I will verify the answer on the other thread.

Chris

I can also confirm that this works.