Post Go back to editing

SC589-MINI issues error at programming the flash.

Category: Software
Software Version: CCES 2.9.4

Hi,

About two years ago we have used the SC589-MINI board to run a convolution app; it runs fine.
Now we bought the same board version 2.1 and tried to program the flash with the existing unmodified app using "prog_SAM_flash_ice1000.bat <app-name>", which resulted in
"Error: failed erasing affected sectors" and led1 is on (red).

This error appears at the beginning of flashing after the ldr file is written; no "running dots" are seen.
Next we have rebuild app-name_Core0, app-name_Core1.dxe, app-name_Core2.dxe and tried to program the flash again with the same result.

Finally we tried to run the app with CCES2.9.4 Debug. The program seems to load properly, but does not run.

Which difference(s) between board version 2.1 and the former one 1.5 could cause this issue?

Regards,
Reinier van der Welle
Eminent Organs BV
The Netherlands

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

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

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

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