• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 98 subscribers
  • Views 1378 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.

LM_post and LM_pend

Ganz
Intellectual 770 points
Other Parts Discussed in Thread: SYSBIOS

We have a custom board that occasionally get abort() error. When it fail, from UIA I can see there are tons of LM_post and LM_pend of one GateMutex created by Sysbios. From ROV I can see the address of the GateMutex but I have not been able to find out who is using that GateMutex. What is the best way to fine out who is using the GateMutex created by Sysbios?

GanZ

  • 0
    TI__Mastermind 22760 points

    Hi GanZ,

    In ROV, you should see the owner of the GateMutex in the 'Basic' tab.  You should also see a list of pending tasks.  For example:


    You can also see what tasks are blocked on in the Task 'Detailed' view of ROV, e.g.:

    Are you able to see such information in ROV?

    Best regards,

        Janet

  • 0 in reply to janet
    Intellectual 770 points

    he owner is NA and there is no task pending on that GateMutex.

    GanZ1070.GateMutexOwner.docx

  • 0 in reply to Ganz
    TI__Mastermind 22760 points
    Hi Ganz,
    Can you look at the BIOS -> Scan for Errors in ROV when your program aborts and see if that gives you any more information?
    Best regards,
    Janet
  • 0 in reply to janet
    Intellectual 770 points

    BIOS -> Scan reports that "An exception has occurred!" See attached file. Below is the register dump.

    A0=0x0 A1=0x0
    A2=0x0 A3=0x1000003
    A4=0x20bf0004 A5=0xa0d5
    A6=0x0 A7=0xb79cc101
    A8=0x0 A9=0xa0
    A10=0x0 A11=0x0
    A12=0x0 A13=0x0
    A14=0x0 A15=0x0
    A16=0x0 A17=0x0
    A18=0x45fa0000 A19=0x80
    A20=0x0 A21=0x0
    A22=0x8d065050 A23=0x12c08201
    A24=0x141a6000 A25=0x81810
    A26=0x2310e2c5 A27=0x41032b
    A28=0x428000b A29=0x70
    A30=0x58 A31=0x9d09de16
    B0=0xa80 B1=0x1
    B2=0x9f40100c B3=0xb78d9d18
    B4=0x0 B5=0x2
    B6=0x23 B7=0x18
    B8=0x3 B9=0x15000103
    B10=0x0 B11=0x0
    B12=0x0 B13=0x0
    B14=0xb808da30 B15=0x9f401000
    B16=0x2 B17=0x9f401dd8
    B18=0xf70a3d00 B19=0x2
    B20=0x800465 B21=0x41493a22
    B22=0xf B23=0x0
    B24=0xa4c16e B25=0x85910184
    B26=0xca16185f B27=0xca16185f
    B28=0x47 B29=0xffffffff
    B30=0x0 B31=0x9f401d1c
    NTSR=0x10204
    ITSR=0x20f
    IRP=0xb7940f76
    SSR=0x0
    AMR=0x0
    RILC=0x0
    ILC=0x0
    Exception at 0x82b5f0
    EFR=0x2 NRP=0x82b5f0
    Internal exception: IERR=0x9
    Instruction fetch exception
    Opcode exception
    xdc.runtime.Error.raise: terminating execution

    3482.AbortError.docx

    GanZ

  • 0 in reply to Ganz
    TI__Mastermind 22760 points
    Hi Ganz,
    What platform are you running on, and what version of SYSBIOS?
    Thanks,
    Janet
  • 0 in reply to janet
    TI__Mastermind 22760 points
    Can you see what code is at NRP? It should contain the address of the code that caused the exception. Maybe you branched to a bad location.

    Best regards,
    Janet
  • 0 in reply to janet
    Intellectual 770 points
    Janet,

    Thanks for the help.
    We are using Sysbios 6.42.1.20 on C6655.
    The NRP is at ti_sysbios_family_c64p_Hwi_int14() or ti_sysbios_family_c64p_Hwi_dispatchAlways() , which is the Hwi for the system tick.

    Is there a list of the C standard library functions that use the bios lock?

    Gan
  • 0 in reply to Ganz
    TI__Mastermind 22760 points
    Hi Gan,
    We think the code at or near the location in the NRP maybe be getting overwritten. Can you try disassembling the code 0x82b5f0 (assuming it's a legitimate address) before and after the exception, and see if any of it changes?
    Thanks,
    Janet
  • 0 in reply to janet
    Intellectual 770 points
    Janet

    The issue is caused by using L2SRAM EDC without scrubbing. The LM_post and LM_pend are not the cause of the issue, they are the results of the system_printf of the register dump.
    Thanks,
    GanZ