• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 102 subscribers
  • Views 693 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

strange SYS/BIOS IPC problem

Jane Mary
Prodigy 170 points

I use IPC between core0 and core7 with IPC_attach function.And I met a strange problem:
when the first time I load the two .out files,the two cores can't attach with each other.
But if I step in the .c files or reload the .out files in debug environment,it works well.
I dont't know what the problem is.
appreciate for your help!

bios 6_33_05_46
ipc 1_24_03_22
ccs 5.2

  • 0
    TI__Mastermind 18260 points

    Can you tell me more about the failure scenario?  How are you loading the two cores when it fails?  What are the DSPs doing when they can't attach to each other?  Have you looked at SYS/BIOS output (either in the CCS "console", or with SYS/BIOS's ROV tool)?

    As for your "working" case, can you describe more?  How are you stepping the two cores?  Is the "debug environment" just the two core executables compiled in "debug" mode?

    Which core do you start first?

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    TI__Mastermind 20790 points

    Jane Mary,

    Please check the example code for multicore at the IPC, and also find the Readme file for how to test/run.

    C:\ti\ipc_1_24_03_32\packages\ti\sdo\ipc\examples\multicore\evm667x

  • 0 in reply to Robert Tivy
    Prodigy 170 points

    I have found that if I use the ti.platforms.evm6678,it works well,core0 and core7 can attach to each other.

    But if I use my own platform,it doesn't work,core0 and core7 can't attach to each other.
    Here are my platform.


    I don't think there is any problem in my platform.But the result is that it doesn't work.

    I'm very confused.Hope for your answer.Many thanks!

  • 0 in reply to Jane Mary
    TI__Mastermind 18260 points

    Could you reply with the "working" and "nonworking" .map files attached?

    The .map file should be present in the <app_dir>/package/cfg subtree.

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Prodigy 170 points
    I have compared the two .map files and there are few differences except the L2 address.For example,one is global address as 0x10800000 and the other is local address as 0x00800000.So I changed the L2 address in my platform from global address to local address and it really works!
    But as I know,the effect of the two situations is the same in fact.Or is there any difference I ingorned?
    Many Thanks!
  • 0 in reply to Jane Mary
    TI__Mastermind 18260 points

    Jane Mary said:
    So I changed the L2 address in my platform from global address to local address and it really works!
    But as I know,the effect of the two situations is the same in fact.Or is there any difference I ingorned?

    The addresses 0x00800000 and 0x10800000 have different MAR registers controlling their cacheability (and prefetch).  The MAR register for 0x00800000 is MAR0 (at address 0x01848000, and it is "fixed", i.e., can't be written) and the MAR register for 0x10800000 is MAR16 (at address 0x01848040, and it is *not* fixed).  Perhaps that's what is causing the difference, and if not then I don't know what's causing the difference.

    I have a Keystone 2 test build that shows MAR0 = 0x1 and MAR16 = 0xc.  I believe the 0x1 bit (bit 0) controls the "cacheability".

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Prodigy 170 points

    Thanks very much!