• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 2 answers
  • Subscribers 102 subscribers
  • Views 760 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.

TDA4VM: C7x IPC Issue

user6229667
Prodigy 100 points
Part Number: TDA4VM

Hi~

Recently I tested running Vision_apps, when I tried to use share memory between MCU2_1 and C7x, I found that C7x sometimes read data form share memory failed.

The code I runed on C7x is as below:

AppMemCacheInv(addr, size);

memcpy(data, addr, size);

A probability of one in ten thousandth may be wrong.

  • 0
    TI__Genius 10355 points

    Can you provide some more details? Like cache settings and region settings on MCU 2_1, MMU page table setting and cache settings on C7x?

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    Prodigy 100 points
    Hi Shyam Jagannathan,
    Thanks for reply.
    The code of C7x to config share memory is the same as the  '/vision_apps/apps/basic_demo/app_tirtos/c7x_1/main.c'. Concrete code is as below:
    Mmu_initMapAttrs(&attrs);
    attrs.attrIndx = Mmu_AttrIndx_MAIR7;
    ...
    retVal = Mmu_map(DDR_SHARED_MEM_ADDR, DDR_SHARED_MEM_ADDR, DDR_SHARED_MEM_SIZE, &attrs); /* ddr */
    if(retVal == FALSE)
    {
    goto mmu_exit;
    }
    The config of MCU2_1 is the same as the '/vision_apps/apps/basic_demo/app_tirtos/mcu2_1/linker_mem_map.cmd'. Concrete code is as below:
    /* Memory for shared memory buffers in DDR [ size 512.00 MB ] */
    DDR_SHARED_MEM : ORIGIN = 0xAE000000 , LENGTH = 0x20000000
  • 0 in reply to user6229667
    TI__Genius 10355 points

    Hi,

    Thanks for providing details, on the MCU2_1 side are you updating the data every time? Also can you please tell the cache operations done on MCU2_1?

    You might have to do a cache writeback on MCU2_1 before sending an interrupt to C7x to read it.

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    Prodigy 100 points
    Hi~
        Why this function is call twice in C7x memory operation?
    void appMemFence()
    {
    #if defined(C71)
    _mfence();
    _mfence();
    #endif
    }
  • 0 in reply to user6229667
    Prodigy 130 points

    A72 transfers data to C71 through shared memory. When C71 reads shared memory, It often reads the wrong data with appMemCacheInv.

    But,  When C71 reads shared memory : appMemCacheInv + memcpy + appMemCacheWbInv , it is ok!

    why? 

  • 0 in reply to michael cui
    TI__Genius 10355 points

    "A72 transfers data to C71 through shared memory. When C71 reads shared memory, It often reads the wrong data with appMemCacheInv."

    Can you please let us know how you are checking if the data is wrong?

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    Prodigy 130 points

    hi,

    A72 writes  4-bytes integer data to shared memory, and sends the 4-bytes integer to c71 through IPC. 
    After C71 receives the IPC, it compares the data the IPC receives with the data it reads from shared memory.

    Then C71 sends ack + integer to A72. After A72 receives ACK, it confirms whether the integer in ack is the integer sent last time, and then sends next time．

    thanks!

  • 0 in reply to michael cui
    TI__Genius 10355 points 
    Thanks for letting us know,

    As of today there is a software issue because of which auto cache coherence does not exist between C7x and A72.
    So we have to do cache operations as below,
       1. When A72 writes do a cache WB and on C7x to read do a cacheInv.
       2. When C7x writes do a cache WB and on A72 to read do a cacheInv.
    The software bug is expected to be fixed in the subsequent SDK release so till then cache ops are required.
    Regards,
    Shyam
  • 0 in reply to Shyam Jagannathan
    Prodigy 130 points

    generally :

        C7x read：cacheinv + memcpy
        C7x write：memcpy + cachewb

    but, A72-> C7x:

        C7x read：cacheinv + memcpy + cachewb
        C7x write：memcpy + cachewb

    When C71 reads shared data from A72 ,  C71 must add CacheWB.  This will solve the problem temporarily. Is it right?

    thanks!

  • 0 in reply to michael cui
    TI__Genius 10355 points

    Hi,

    C7x read: cacheinv + memcpy (is the destination, DDR or L3 or L2)

    If the memcpy destination is DDR we will need a cachewb but if the destination is L2 cachewb is not expected.

    Also this is assuming that you have programmed C7x MMU accordingly.

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    TI__Intellectual 2235 points

    Reply on behalf of Michael Cui.

    C7x read share memory data from A72:   cacheinv + memcpy， ---failed

    C7x read share memory data from A72:  cacheinv + memcpy + cachewbinv, ---OK

    C7x write share memory data from A72: memcpy + cachewb, ---OK

    I think we do not need cachewbinv operation for reading.  What is the effect of cachewbinv?

  • 0 in reply to Ming Zhong10
    TI__Genius 10355 points

    C7x read share memory data from A72:   cacheinv + memcpy， ---failed

    Can you please let me know what is the destination address of the memcpy? If the destination address is DDR, then a cachewbinv may be required, if the destination address L2 SRAM then cachewbInv is not required.

    Regards,
    Shyam

  • 0 in reply to Shyam Jagannathan
    TI__Intellectual 2235 points

    Thanks Shyam. Destination Addr is DDR.

    After a call with Michael Cui, I can help add more details: He might not express clearly.

    1. A72 write data to Shared DDR, then do a CacheWB. Correction: no CacheWB, but they use mmap with o_sync option.

    2. C71 do a cacheInv to Shared DDR. If you read the value now, you will have a very small chance to get a wrong value.

    3. C71 do a memcoy to local heap, then do a CacheWB, We can get the correct result all the time.

    ZM

  • 0 in reply to Ming Zhong10
    TI__Genius 10355 points

    ZM,

    3. is expected behaviour. If you want to "view" the contents of local heap  in DDR with the latest values, you will have to to a CacheWB for the changes in L1D write buffer to be committed to DDR.

    As an experiment, you can try changing the destination address to L2SRAM. Here you will not require a CacheWB as L1D and L2 are coherent. I hope this answers your question.


    Regards,
    Shyam