• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 1023 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.

RTOS: Syslink GatePeterson_enter() blocking other interrupts.

VinceGads
Prodigy 220 points
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI-RTOS

Hello,

I am having a problem where the function GatePeterson_enter() is called and invalidated the cache for long duration, up to 5ms seen. During this time, none of my interrupts can be served. It is a major problem here as our motor control SWI is not executed as expected every 300 micro-second (clock timer triggered).

I have also found that the event dispatched in the sysbios is also no served during this time.

Have you ever seen such a problem ?

Thank you,

Vincent

  • 0
    TI__Guru**** 393215 points
    What processor is this? What software? Which version?
  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points
    OMAP L138 and ipc_1_25_03_15.

    We also use:
    syslink_2_21_03_11,
    bios_6_37_05_35,
    biospsp_03_00_01_00

    Best regards,
    Vincent
  • 0 in reply to VinceGads
    Prodigy 220 points
    Hi Biser,

    Have you got time to look at the issue ?
    I am trying to completely disable the cache for IPC at this point. Do you know where I could disable it on the ARM side ? We are using linux.

    Thank you,
    Vincent
  • 0 in reply to VinceGads
    TI__Mastermind 27355 points

    Hi Vincent,

    I'm not familiar with the syslink package, only with the ipc package that comes with Processor SDK so my support will be limited, but I found a thread that might help:

    Referring to the post by Arnie, it appears syslink assumes all memory to be non-cached for all SharedRegions on the host-side, by default.

  • 0 in reply to Sahin Okur
    Prodigy 220 points

    Hi Sahin,

    Thank you for your response.

    It is funny at this point I am trying to do the opposite. I want to remove the cache on the shared memory.

    When I do so, my code does not start anymore. I basically update the configuration of the shared memory in the config file as following:

    var icc_mem_region = Program.cpu.memoryMap["DDR_SHARED"];
    var sr0            = new SharedRegion.Entry();
    sr0.base          = icc_mem_region.base;
    sr0.len           = icc_mem_region.len;
    sr0.ownerProcId   = Ipc.hostProcId;
    sr0.isValid       = true;
    sr0.cacheEnable   = false;
    sr0.cacheLineSize = 0;
    sr0.name          = "SR0";

    When I do so I completely lose the creation of the ICC channels and the ARM side is not able to bind to it.

    Any idea what I configured wronglyon the DSP side ?

    thanks,

    Vincent

  • 0 in reply to VinceGads
    TI__Mastermind 27355 points

    Hi Vincent,

    sr0.cacheEnable does not actually enable or disable cache. It is just meant to specify to IPC whether cache is enabled or not. In order to disable cache on the DSP you will need to set the corresponding MAR bits in your config file. For example, the following line would set region 0xc0000000 -> 0xdfffffff to be non-cached.

    /* Set 0xc0000000 -> 0xdfffffff to be non-cached for shared memory IPC */
Cache.MAR192_223 = 0x00000000;

    Refer to section 4.4.4 of the C674x DSP Megamodule Reference Guide for a list of all MAR registers.

    http://www.ti.com/lit/ug/sprufk5a/sprufk5a.pdf#page=99

    According to this thread, 

    the following lines should disable cache on the ARM side in Syslink.

    SysLink_setup();

SysLink_params = "SharedRegion.entry[1].cacheEnable=FALSE;";  //Change 1 to the sharedRegion id you want to cache

    I hope this helps.

  • 0 in reply to VinceGads
    Prodigy 220 points
    Actually, I was able to disable the cache.

    I still see the function GatePeterson_enter() blocking every other execution. Can you point me in the direction of document regarding the function. I would like to understand when it is called.
    I see it has a while loop waiting for the resource. So am I wondering if my problem is not due to resource contention with the ARM ?

    Thanks
  • 0 in reply to VinceGads
    Guru 26430 points
    This might not apply to your situation at all. My experience is with DSPLINK/DSPBIOS. I found that if specify an infinite wait on an object get (eg. message queue get), the ARM and DSP get into some sort of deadlock. My work-around at the same was so busy spin with zero wait on the DSP side. It seemed to allow avoid entering a deadlock. If it matters, I was using the L3 RAM as my IPC memory.
  • 0 in reply to Norman Wong
    Prodigy 220 points

    Hi Norman,

    Thank you for your response, fortunately (or not) we always set up defined time out.

    Cheers

  • 0 in reply to VinceGads
    Guru 26430 points
    In my opinion, timeouts are fortunate... Is your timeout about the same as your problem delay? Perhaps try zero timeout and retry a limited number of times before giving up.