Post Go back to editing

ADSP-SC58x: how to debug a fatal error in the ARM core?

HI,

my project has a very very rare crash condition that breaks the ARM core. Using the ICE debugger I can see that the ARM core ends in the __fatal_error ASM routine, while the DSP cores keep on running.

I need to figure out how this happened, but there is no stack trace in the ARM if I stop after the crash. I have been reading the CCES 2.9.0 C/C++ Library Manual for SHARC Processors and I see that there are several global variables that could help me out: _adi_fatal_error_general_code, _adi_fatal_error_specific_code, and so on.

Unfortunately, it seems to me that these symbols are not present in the ARM symbol map, but only in the DSP  (I can see their address in the DSP .map.xml files).

Therefore 3 questions:

- how can I debug a fatal error in the ARM?

- shouldn't you clarify in the C++ Library Manual that the_adi_fatal_error_* global variables are available only in the DSP? If this is an error on the guide this is very disappointing.

Best regards

  • I have gone further and discovered that:

    - the ASM routine fatal_error is called by exceptions that set the registers R0 and R1

    Now I know the kind of error (runtime error 0x503).

    However, I would probably like to know the program counter where the error happened. Is this possible?

    One last question: I see from other forum posts that the CCES should give me a very detailed report like this:

    A non-recoverable error or exception has occurred.
    
    Description: Data Fault Exception - caused by attempting to access invalid data memory.
    
    General Type: RunTimeError
    
    Specific Type: ExceptAbrtData
    
    Error Message: If this is a synchronous fault, address 0x310010a0 held in Data Fault Address Register (DFAR) is the problem address.
    
    Error PC: 0xc1005124

    Why does this not happen to me? The debug session does not even stop and the Debugger console is empty ("No console to display at this time"). What is wrong? I had to figure out by myself that the ARM crashed, pause the processor and look at the disassembly to discover that the system was in fatal_error and was going to loop into a NOP forever.

    How can I have the detailed report printed in CCES?

  • Hi,

    The IDDE should automatically set a breakpoint at "__fatal_error", and print the report when this breakpoint is hit. Can you check that this breakpoint exists and is enabled? The automatic breakpoints are listed separately from user breakpoints - you can find them under the " Automatic Breakpoints" tab for your debug configuration. Regardless of this, you should find the address where the error occurred in R2 once the "fatal_error" function is called.

    Regarding the global variables, I've tried creating a small ARM executable and they seem to be defined (i.e. I can view them in the debugger's expressions window). Can you try accessing them *without* the leading underscore?

    Thanks,
    Kenny

  • Hi Kennie, apologies for reviving an old post but I thought it better than posting a separate similar thread.

    I have an SC573 running FreeRTOS on the Arm core and am experiencing a rare but pernicious  fatal error. Like the OP I have no report printed to the console, but could this be due to having semi-hosting disabled (as per Analog Devices FreeRTOS user guide)?

    I have confirmed that the fatal error breakpoint is set for core0.

    Is there any other way to diagnose the cause of a fatal error, as there is not call stack?

    Many thanks

    Connor