• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 883 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.

SYS/BIOS 6.32 exception

Balaji Arumugam
Intellectual 280 points
Other Parts Discussed in Thread: SYSBIOS

Hello,

As our C6678 DSP application using SYS/BIOS exceeds 512KB, I'm trying to place the memory sections in the multi-core shared memory "MSMCSRAM" by modifying the SYS/BIOS configuration file. I'm getting a run time exception while initializing the task parameters using the BIOS API "Task_Params_init(&taskParams)". Kernel object view ROV displays "Internal Fetch Packet exception" . Below is the disassembly code when the exception occurs:

0c001c78: 1FFC7413 CALLP.S2 ti_sysbios_knl_Task_Params_init (PC-7264 = 0x0c000000),B3

0c001c7c: 120005FC || ADDAW.D1X B15,5,A4

ti_sysbios_knl_Task_Params_init:

0c000000: 12345678 DPACKX2.L1X A2,B13,A5:A4                                                 <- exception

0c000004: 9ABCDEF0 [!A1] DMV.S1X A6,B15,A21:A20

I've attached the SYS/BIOS (*.cfg), map and exception dump files, can anyone know why I'm getting this exception and what is needed in addition to run the code from multi-core shared memory ?

Thanks,

Balaji

test.zip
  • 0
    TI__Mastermind 32475 points

    Balaji,

    Are you trying to run this from multiple cores?  Having data in MSMCRAM is a problem because each core is going to overwrite another cores changes.  You can only put CODE and constant DATA in MSMCRAM if you are building a single executable.  Otherwise, you need to build multiple executables and breakup MSMCRAM between the different programs.

    Judah

  • 0 in reply to judahvang
    Intellectual 280 points

    Judah,

    As we are still working on the design how to download the code on to off-chip DDR3 from the host PowerPC via SRIO directIO, for now we are trying to get the single core running from the shared memory and later investigate the options to run multiple cores.

    -Balaji    

  • 0 in reply to Balaji Arumugam
    Intellectual 280 points

    Judah,

    FYI, I've also tried placing only .text code section in the shared memory, still have the same exception. we want to try placing the data sections on to individual corepac L2 or other available memories when we get the application running using single core on C6678 similar to what we have right now using C6455.  Let me know if you have any information why this exception might be occuring ? 

    -Balaji 

  • 0
    TI__Mastermind 18260 points

    Balaji Arumugam said:

    0c001c78: 1FFC7413 CALLP.S2 ti_sysbios_knl_Task_Params_init (PC-7264 = 0x0c000000),B3

    0c001c7c: 120005FC || ADDAW.D1X B15,5,A4

    ti_sysbios_knl_Task_Params_init:

    0c000000: 12345678 DPACKX2.L1X A2,B13,A5:A4                                                 <- exception

    0c000004: 9ABCDEF0 [!A1] DMV.S1X A6,B15,A21:A20

    The code you list above is indeed not code, but I believe you're misinterpreting things a little - the NRP register is the location of your exception, and your exception dump shows NRP as 0x00000000.  I do notice that the exception dump shows IRP as 0x0c000000, which is perhaps why you're focused on that code area, but the IRP value is merely the last location to which an interrupt returned (or, if the exception happens inside an interrupt routine, IRP is where that interrupt would've returned had the exception not happened).

    It is indeed odd that the code dump at 0x0c000000 (with the function label ti_sysbios_knl_Task_Params_init) shows garbage, perhaps it got overwritten somehow, or you don't have the memory setup correctly.

    You need to figure out why your code is jumping to 0x00000000.  I notice that register B3 in your exception dump is 0, which I've never really seen in a working system.  I suspect that B3 got restored from a bad stack and some function was attempting to return through it (B3 is the C6x function return register).  You should check the various stacks in your app (thru ROV), perhaps one overflowed.

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Intellectual 280 points

    Rob,

    Further testing, found that only first 64 bytes in the shared memory from 0x0C000000 to 0x0C00003F don't get initialized with the code while downloading from powerPC via SRIO directIO. The reason still unknown, hence 0x0C000000 contains invalid opcode (actually corresponds to "ti_sysbios_knl_Task_Params_init" as per the map file). However while instruction single stepping found that core0 executes the invalid code and eventually ends up with an exception. However SRIO Linux driver on PowerPC doesn't show any expected errors that it couldn't write those remote DSP memory locations corresponding to the shared memory. May be I will move this post to the SRIO forum.

    -Balaji    

  • 0 in reply to Balaji Arumugam
    TI__Mastermind 18320 points

    This thread appears to have been continued in another forum at http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/187410.aspx.  So I will go ahead and mark this one as closed.