Post Go back to editing

Core crashes during Audio Play Back

Category: Hardware
Product Number: ADSP-21593

Hi Team,

Core2 crashed after 12 to 14 hours of audio playback.

When we try to load symbols and check, it is observed that from a function return instruction fatal error is observed.

I hope these instructions in assembly assembly are related to the return statement of a function

i12=dm(m7,i6);

jump (m14,i12) (db);

rframe;

nop; 

a fatal error occurs from the statement i12=dm(m7,i6);

Please let us know if there are any possible reasons for this crash to occur. Also let us know if there are any suggestions for debugging.

Please find the register values in the issue case

It is observed that i12 is 0

When we compare status register of issue and non-issue(working) case, following differences are observed.

 

Please let us know your feedback on this if you have any insights.



Added details of registers
[edited by: sivark at 3:11 PM (GMT -5) on 5 Mar 2024]
Parents
  • Hi Siva,

    Can you please confirm whether you are referring to any audio playback example which is available under ADSP-2159x BSP

    https://download.analog.com/tools/EZBoards/EV-SC59x/Releases/Release_3.0.0/ADI_EV-SC59x_EZ-KIT-Rel3.0.0.exe

     Let us know the rate of failure and confirm what is the sampling frequency you are using.

     To check the stack overflow. The compiler provides support for detecting stack overflows. You can enable stack overflow detection via Project > Properties > C/C++ Build > Settings > Tool Settings >CrossCore SHARC C/C++ Compiler > Run-time Checks > Generate code to catch a Stack.

     When stack overflow occurs at that time the stack overflow interrupt is triggered and also the "_adi_stack_overflowed" function is called by default. The stack is implemented as a circular buffer using I7. When stack overflow detection is enabled, the corresponding circular buffer overflow interrupt (CB7I) is enabled.

     Could you please check the status of the registers IMASK.CB7I and I7.

     We recommend to refer the section "Stack overflow detection" in the Compiler Manual for SHARC Processors linked below:

    https://www.analog.com/media/en/dsp-documentation/software-manuals/cces-SharcCompiler-manual.pdf

     Please note, SSOV bit is a sticky bit. Sticky bits do not clear themselves after the condition is no longer true. They remain "sticky" until cleared by the program. Interrupt service routines (ISRs) must clear their interrupt's corresponding sticky bit so the processor can detect a re-occurrence of the condition.

    Regards,
    Ranjitha R
  • Thank You for the response.

    We are not referring to any example available in BSP. 

    The rate of failure is almost 100% but it occurs after a long run(18 to 20 hours of audio playback)

    Sample Frequency is 48KHz2.

    I have added  "-rtcheck-stack" flag and built the code.

    When the issue occurs when I try to check IMASK.CB7I bit is not set.

    Can you please let us know? This means the Overflow does not occur, or overflow interrupt is not enabled(Flag "-rtcheck-stack" not set properly).

Reply
  • Thank You for the response.

    We are not referring to any example available in BSP. 

    The rate of failure is almost 100% but it occurs after a long run(18 to 20 hours of audio playback)

    Sample Frequency is 48KHz2.

    I have added  "-rtcheck-stack" flag and built the code.

    When the issue occurs when I try to check IMASK.CB7I bit is not set.

    Can you please let us know? This means the Overflow does not occur, or overflow interrupt is not enabled(Flag "-rtcheck-stack" not set properly).

Children
  • Hi Siva,
    REGF_STKYX.SSOV indicates that the status stack is overflowed (=1) or not overflowed (=0). Please check the REGF_STKYX.SSOV bit.
    Can you please try to increase the stack size and check. It can be done using system.svc > Startup Code/ LDF tab > LDF > change size in System Stack
    Are you using freertos in your application. If so, without freertos does application behaves correct?
    Also please share us the screenshot of fatal error.
    Regards,
    Ranjitha.R