Post Go back to editing

SHARC sigma studio example firmware stop working after 2^32 samples processed

Category: Software
Product Number: ADSP21569
Software Version: CCES 2.9.4

Hi support,
i'm running an hard to debug issue with Sigma Studio framework example firmware and CrossCore 2.9.4 on ADSP21569 eval board
After 2^32 samples are processed the output stop play sigma studio processed output but keep playing last "block size" samples ( 64 for in my case ).
At this point the output buffer continue playing that old data also if the other part of the firmware, input + sigma studio processing work fine.
Seem that copy from sigma studio outputs to SPORT output buffer is broken but i need help to understand what is happening in detail, i don't see any issue with DMA interrupt and stuff around the buffer copy.
Thank you in advance.

  • Hi Shooks,

    Could you please let us know which SigmaStudio example framework you are using?
    are you using ADSP-21569 EZKIT or EV-21569-SOM  board?


  • Hi Sakthivel P,
    thanks for quick replay,
    I'm using EV-21569-SOM with BSP "EV-2156x_EZ-KIT-Rel1.0.1" on "Sigma Studio 4.6" with SHARC plugin for 4.6 "sigmastudioforsharc-adspsc5xx-rel4.6.0_bundle" and CCES 2.9.4.
    The example i'm running is "Demo" example provided with the bundle ( where sigma studio schematic is indipendent ) .
    C:\Analog Devices\SoftwareModules\SigmaStudioForSHARC-SH-Rel4.6.0\Target\Examples\Demo.
    Thank you in advance.

  • 2^32 samples means more than 24 Hrs. Please let us know more details on your program and I am eager to know the use case for playing audio for 24 Hrs.
    We will investigate on this issue and get back to you.

  • Yes more then 24 Hrs.
    Our program right now is exactly the example program provided with Sigma Studio for SHARC bundle 4.6.
    We would like to use it as base point for our product that will be a rack amplifier.

    But right now our goal is to test stability and robustness of the base firmware with eval board to know if make sense to use it as starting point for development.

    Then next step for the real product is configure it to run at 96KHz ( that mean hang output buffer in ~12 Hrs ) changing PCG and DAI routing according with our needs, but this is step 2.

    It's common that a rack amplifier stay powered playing audio for 24 Hrs.
    Keeping the EVAL board turned on for more then 24 Hrs we see this unexpected behavior.
    Thank you in advance for the support.

    Thank you in advance.

  • Hi Shook,

    I have started the long run testing on ADSP-21569 SOM from 07/06/2022 5.30 PM (IST) to today 09/06/2022 10.00 AM(IST). There is no such an issue reported by you and audio is still fine even after 40 Hrs. 

    Please find the setup information as below,
    CCES 2.9.4
    SigmaStudio 4.6
    SigmaStudio 4.6.0
    Target FW example: C:\Analog Devices\SoftwareModules\SigmaStudioForSHARC-SH-Rel4.6.0\Target\Examples\Demo\ADSP-2156x\ADSP-21569
    DXE used: prebuilt DXE in release build
    Eval Board: ADSP-21569 SOM with EV-SOM-CRR EZKIT

    I am doing the long run test even in CCES emulator mode using ICE- 1000.

    Could you please check and confirm you end, Is this issue always reproducible? 

  • Hi Sakthivel,
    yes it is.

    What kind of signal do you use to see board output ?

    Because if you are using a sine wave it can look valid on RTA or OSC also when the output buffer is "broken" playing latest "block size" samples.

    Consider that when output buffer is broken, Inside the Sigma Studio everything look fine from inputs to outputs.
    if you change parameters like gains or mute they seem to work properly looking at signal flow vmeter also when the output buffer is broken.

    Thank you for the great support.

  • Hi Shooks,

    I have used the example schematic "Volume_Mute_Block_2156x.dspproj" present in 
    "C:\Analog Devices\SoftwareModules\SigmaStudioForSHARC-SH-Rel4.6.0\Host\Examples\Sample Schematics\ADSP-2156x" folder and I have given analog audio input from PC over ADC inputs.

    If you are using "Sine Tone" module for long run due to precision loss there was some instability with the module which may cause unexpected output.