• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1923 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.

Fetch Packet Exception to Op-Code Exception to Resource Conflict

Chia-Ning Wang
Intellectual 400 points


Hi,

     I'm trying to move a significant portion of our program code from the default .text section in Shared L2SRAM to custom sections in DDR and encounter Fetch Packet Exception, Op-Code Exception and Resource Conflict Error when I try to run the compiled project. These errors appear limited to instances where code in the .text section calls code in DDR and error usually occurs on the first 1-3 execute packets after the branch.

An example of one of the FP errors is shown below:

[C64XP] A0=0x1 A1=0x0
A2=0x0 A3=0x1
A4=0x80f064 A5=0x80f0f8
A6=0x8027 A7=0xff00
A8=0x264eec A9=0x0
A10=0x0 A11=0x0
A12=0x0 A13=0x0
A14=0x0 A15=0x0
A16=0x8023c4 A17=0x0
A18=0x802394 A19=0x20
A20=0x20000000 A21=0x894fbba5
A22=0xe1819812 A23=0x0
A24=0xffffffff A25=0x400
A26=0x80000000 A27=0x1
A28=0x803ee0 A29=0xe
A30=0x803ed4 A31=0x206c40
B0=0x1 B1=0x0
B2=0x0 B3=0xe7e25518
B4=0x80d78c B5=0xe7e49c20
B6=0x801c38 B7=0xe7e30250
B8=0x802550 B9=0xe7e30250
B10=0x0 B11=0x0
B12=0x0 B13=0x0
B14=0x811530 B15=0x802968
B16=0xfbe00000 B17=0xa00
B18=0x0 B19=0x0
B20=0x69 B21=0xffffffff
B22=0xf B23=0x0
B24=0x0 B25=0x80
B26=0xa20100 B27=0x60
B28=0x40 B29=0x80eabc
B30=0x80eabc B31=0x80232c
NTSR=0x1020f
ITSR=0x20d
IRP=0x2884e4
SSR=0x0
AMR=0x0
RILC=0x0
ILC=0x0
Exception at 0xe822d140
EFR=0x2 NRP=0xe822d140
Internal exception: IERR=0x2
Fetch packet exception

With the last execute packet being the following:

 This code is in a read-only section so it's unlikely to be an errant data pointer corrupting program memory. I've also aligned each custom codesection to 8-byte boundaries. Any advice would be greatly appreciated!

  • 0
    TI__Mastermind 18256 points

    Hi Chia-Ning,

    given the information you provided I'm pretty convinced this is actually an errant data pointer corrupting program memory or a EDMA transfer going wrong.

    If the corruption happens always at the same places you could configure a data watchpoint to catch the access if performed by the CPU. An EDMA corruption is harder to track down.

    Here's a link on information about watchpoints. It's using on older version of CCS to explain but the principles still apply:

    Kind regards,

    one and zero

  • 0 in reply to one and zero
    Intellectual 400 points

    Hi one and zero,

    Thanks for suggesting the tool. I tried setting the watchpoint at the address range of interest but the breakpoint never activates. Just to be sure the watchpoint was working I placed the watchpoint in memory locations that I know are written to by data pointers and edma transfers and they both worked (the latter halts at SharedRegion_getSRPtr). Seeing as that rules out program corruption are there any other suggestions?

    Best Regards,

    Johnny

    Edit: Further digger suggests the problem is address-specific. I took working code, placed them into the troubled address and encountered similar error. I took troublesome code and placed them into another DDR section and the code runs successfully. This seems to suggest program corruption, however, based on the broad address range (at least 14MB) the error presents itself I doubt it's EDMA corrupting program code. I'm not sure how fruitful an attempt to examine each 32-bit instruction would be. Please advise.

  • 0 in reply to Chia-Ning Wang
    TI__Mastermind 18256 points

    Hi Johnny,


    the corruption could be caused by any master in the SoC (e.g. master capable peripherals like Ethernet). Which exact device are you using?

    Another thing you can try but will be much more work intensive is to use memory protection. See:

    http://processors.wiki.ti.com/index.php/MemoryProtectionOnKeystoneDevices

    Kind regards,

    one and zero

  • 0 in reply to one and zero
    Intellectual 400 points
    Sorry forgot to mention:

    Device: C6472
    Enabled Peripheral: SRIO only for bootup
    IDE: CCS 5.5
    Compiler: TI v7.2.6
    XDCtools: 3.25.3.72
    SYS/BIOS: 6.35.4.50
    IPC: 1.24.3.32

    I will look into the memory protection. I've been putting the code into a separate DDR section created using the RTSC Platform UI with permission set to 'RX' and assumed that would trigger complaints if writes get performed on the code.
  • 0 in reply to Chia-Ning Wang
    TI__Mastermind 18256 points

    Hi Chia-Ning,

    how many cores are running when you see the corruption?

    Do you see the error as well when running just a single core?

    Are you using your own designed custom board or an EVM?

    Kind regards,

    one and zero

  • 0 in reply to one and zero
    Intellectual 400 points
    Hi one and zero,

    Thank you for all your help and sorry for the late reply. The source of error came from the host device that was loading the DSP.

    Best Regards,

    Johnny