• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 563 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.

MessageQ problem with kicker

aloras
Intellectual 450 points

Hi,

I prepare a firmware project in which core0 and core1 communicates with each other as a rate of 50Hz by using IPC MessageQ structure. I have observed that when I lock the kicker at the beggining of the communication, thay cannot communicate. But if I unlock the kicker they can communicate. So is there a relationship between IPC messageQ APIs and kicker mechanism? Do you have any suggesion?

Thank you

Alpaslan 

  • 0
    TI__Mastermind 20790 points

    Alpaslan,

    There is no relationship between IPC API and Kicker mechanism. But the kicker mechanism will do lock and unlock the registers. This may be cause the issue on our firmware project. 

    The below E2E post is described about the Kicker mechanism.

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/295211/1030482.aspx#1030482 

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/273167/958041.aspx#958041

  • 0 in reply to Pubesh
    Intellectual 450 points

    Pubesh,

    For the demo image_processing project under the mcsdk folder, the master (core0) calls HeapBufMP_create(IMAGE_PROCESSING_HEAP_NAME) and slave_main tasks running all 8 cores waits for it by HeapBufMP_open(IMAGE_PROCESSING_HEAP_NAME). If I put a CSL_BootCfgLockKicker() before HeapBufMP_create() at the master side, then all the slave_main tasks are blocked within HeapBufMP_open() API except that is in the master core. So this also suits with my observation. It seems that there is a relationship between IPC APIs and Kick lock mechanism. I have found it by chance. But I try  to understand that whether I have a mistake or this a normal situation.

    Alpaslan 

  • 0 in reply to aloras
    TI__Mastermind 20790 points

    Alpaslan,

    I do not know why you are trying "CSL_BootCfgLockKicker" for HeapBufMP_create in the image processing demo.

    Please find the detailed information about the kicker mechanism,

    CSL_BootCfgLockKicker() - To used for lock the chip configuration registers to prevent unintentional writes. 
    CSL_BootCfgUnlockKicker() - To used for unlock the kicker to ensure Boot configuration MMR is writeable.

  • 0 in reply to Pubesh
    Intellectual 450 points

    In my application, Core0 initilizes Hyperlink and MessageQ, then it communicates with Core1 over MessageQ. Each Hyperlink API accesing the Device State Control Registers ends with a CSL_BootCfgLockKicker(). I have observed that  Core1 is not returned HeapBufMP_open() API. So if I comment out CSL_BootCfgLockKicker() part it passes.

    So I try to test this situation by using the demo image_processing project where the master (core0) calls HeapBufMP_create(IMAGE_PROCESSING_HEAP_NAME) and slave_main tasks running all 8 cores waits for it by HeapBufMP_open(IMAGE_PROCESSING_HEAP_NAME). If I put a CSL_BootCfgLockKicker() before HeapBufMP_create() at the master side, then all the slave_main tasks cannot return from HeapBufMP_open() API except that is in the master core like my application. İs there any objection to put a CSL_BootCfgLockKicker() anywhere in the code?

    Alpaslan

  • 0 in reply to aloras
    TI__Mastermind 20790 points

    Alpaslan,

    I am not Hyperlink Expert, but I can suggest you should consider the proper initialization. I do not have the reference code implemented for hyperlink as well as IPC. You can refer the SRIO IPC benchmark code available at : pdk_C6678_1_1_2_6\packages\ti\transport\ipc\examples\srioIpcBenchmark . Take this file to look how the  HeapBufMP_open() used in the SRIO.  If possible please provide a code snippet so that we can examine this issue.