• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 1742 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/AM3359: Register dump following exception in ISDK 01.01.02.01 issue

David79
Intellectual 420 points
Part Number: AM3359
Other Parts Discussed in Thread: SYSBIOS, AM3352

Tool/software: Code Composer Studio

Hello,

The title says it all:  The Register Dump following a fatal exception in ind_sdk_01.01.02.01 + bios_6_42_02_29 doesn't preserve the correct SP/LR/PC needed to properly restore the stack backtrace to the point of exception.

Here's an example dump, (note the poor formatting, "[CortexA8]" overwriting "R0 = ").  The big issue here is, it seems PC and/or SP are incorrect -- why is PC always reported equal to SP after a crash?

[CortxA8] 0x0000000f R8 = 0x80106c90
R1 = 0x0000c75f R9 = 0x000000ff
R2 = 0x48200048 R10 = 0x00000000
R3 = 0x822f540c R11 = 0x00000002
R4 = 0x800582b0 R12 = 0x0000000f
R5 = 0x800582b4 SP(R13) = 0x8004b8d4
R6 = 0x48200068 LR(R14) = 0x822edd6c
R7 = 0x00000000 PC(R15) = 0x8004b8d4
PSR = 0x000000ff
DFSR = 0x00000005 IFSR = 0x00000000
DFAR = 0x0000001f IFAR = 0x00000000
ti.sysbios.family.arm.exc.Exception: line 205: E_dataAbort: pc = 0x8004b8d4, lr = 0x822edd6c.
xdc.runtime.Error.raise: terminating execution

Please advise.

 

Regards,

-david

  • 0
    TI__Guru**** 393215 points
    Hi,

    The ISDK team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Expert 7570 points
    Hi David

    You mentioned using bios_6_42_02_29 .
    ISDK 1.1.2.1 has specific tool requirements . These are listed in the system requirements section of the user guide.

    Code Composer Studio [13] version CCS 6.1.0.00104
    SYSBIOS 6.41.04.54 [14] Real Time Operating System
    XDC 3.30.06.67 [15]
    Compiler version TI v5.1.11
    Network Development Kit (NDK) 2.24.01.18 [16]

    Do you see the same behavior with this tool set?

    David
  • 0 in reply to David Zaucha
    Intellectual 420 points

    Same behavior:

    [CortxA8] 0x0000002e R8 = 0x00000000
    R1 = 0x00000005 R9 = 0x80028a44
    R2 = 0x822f14a8 R10 = 0xffffffff
    R3 = 0x481aa000 R11 = 0xffffffff
    R4 = 0x822f20f4 R12 = 0x00000000
    R5 = 0xffffffff SP(R13) = 0x800243f4
    R6 = 0x00000002 LR(R14) = 0x822edd6c
    R7 = 0x822f51a0 PC(R15) = 0x800243f4
    PSR = 0x80028a44
    DFSR = 0x00000005 IFSR = 0x00000000
    DFAR = 0x00000004 IFAR = 0x00000000
    ti.sysbios.family.arm.exc.Exception: line 205: E_dataAbort: pc = 0x800243f4, lr = 0x822edd6c.
    xdc.runtime.Error.raise: terminating execution

  • 0 in reply to David79
    TI__Expert 7570 points
    Hi David

    It is not unique to this particular release. Any unhandled exception results in a similar behavior.
    When this occurred - I rebuilt the relevant libraries to permit debugging and used breakpoints to locate the failure.

    David
  • 0 in reply to David Zaucha
    Intellectual 420 points
    David,

    Thank you for your reply, I understand how to debug lib calls. I'm chasing a bug that's not easy to reproduce...

    The point of my original post is that this is a *bug* in SYSBIOS's exception handler and/or CSS. Certainly, the exception handler is not performing as intended, or documented. The sole purpose of an exception handler's reg dump is to provide sufficient CPU state for a backtrace. TI's exception handler is broken and offers precious little value. Has this issue been fixed in a subsequent release? If so, which? And if not, when will it be fixed?

    Regards,
    -david
  • 0 in reply to David79
    Guru 92251 points

    David79 said:
    The sole purpose of an exception handler's reg dump is to provide sufficient CPU state for a backtrace. TI's exception handler is broken and offers precious little value.

    I reported a bug in the exception handler - see SYS/BIOS 6.45.01.29 ti.sysbios.family.arm.exc.Exception reports incorrect SP and LR values, leading to incorrect exception call stack, albeit on a later version of SYS/BIOS. In that thread I described the cause of the problem, along with a suggested change to the exception handler code. Pending a formal fix you should be able to place a modified version of the exception handler code in your project with a fix.

    David79 said:
    Has this issue been fixed in a subsequent release?

    Bug SYSBIOS-307 was raised. Just looked through the SYS/BIOS release notes, and SYSBIOS-307 is reported as fixed in the SYS/BIOS 6.50.00.10 GA Release Notes. I will download SYS/BIOS 6.50.00.10 to check.

  • 0 in reply to Chester Gillon
    Guru 92251 points

    Chester Gillon said:
    Just looked through the SYS/BIOS release notes, and SYSBIOS-307 is reported as fixed in the SYS/BIOS 6.50.00.10 GA Release Notes. I will download SYS/BIOS 6.50.00.10 to check.

    Tested SYS/BIOS 6.50.0.10 with an AM3352 using CCS 7.0.0.00042, XDCtools 3.50.0.10 and TI compiler v16.9.0.LTS.

    The following screen shot shot shows the test program at the instruction which will generate an exception:

    And after continuing the decoded exception:

    This shows that the SYS/BIOS 6.50.0.10 has saved the correct exception context since:

    1) The register dump in the CCS console shows the values of the SP, LR and PC registers which match those from the debugger prior to executing the instruction which generated the exception.

    2) The Exception call stack in the ROV view matches that shown in the debugger prior to executing the instruction which generated the exception.

    Note that upgrading to SYS/BIOS 6.50.0.10 imposes some constraints on the tools since:

    a) SYS/BIOS 6.50.0.10 requires XDCtools 3.50.0.10 to be able to compile

    b) XDCtools 3.50.0.10 won't install in CCS 6 due to missing dependencies. The release notes for XDCtools 3.50.0.10 say CCS 7.1.x must be used, but I was able to use with CCS 7.0.0.00042 without any obvious problems.