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.

openem dispatch error

hi everyone,

I'm integrating openem into my own project.But now all cores stuck at the line below in ti_em_dispatch_once:

#ifndef TI_EM_DIST_SW_SCHED /* Normal behavior : the scheduler is centralized either on a PDSP or on a DSP core */
{
// We pop event from head of the PF Queue to get a PF Event or an AP Event
lvEventDscPtr = (volatile Cppi_HostDesc*) (*(uint32_t *)(Emti_gvDcb.pfQueueRegDPtr));
if (lvEventDscPtr == NULL)
return (em_status_t) EM_ERR_NOT_FOUND;
}

the lvEventDscPtr is NULL all the time which means cores failed to get an event from the queue. I already checked that events are successfully sent to queues since em_send returns EM_OK. But I'm not sure whether it is because the event is not transmitted to the receive queue or its the pdsp is off working so an arrived event doesn't trigger an interrupt to a core.

I check the Emti_gvDcb in Expression window once running my project and once running Example_0 demo.

below is what shows when running the demo which should be the correct situation:

But when I running my own project, the pecb part is all 0x00000000.

I wonder what could be the possible operations that make pecb all zero ?

How can I correct it and make sure cores can get a popped event ?

Thank you.

  • Ruijie,

    I am assuming that this is based on the same example from our previous exchange: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/382776#pi239031349=2

    What changes have you made that caused this new behavior? Do you know how I could replicate the issue on my EVM? 

    Start by focusing on any changes made to the private region and private event descriptors in the ti_em_init.c file. 

    Thanks,

    Jason Reeder

  • Hiiii Jason,

    My problem in last thread is kind of solved. But I realized that it's not the real problem I'm facing.

    All I did is that in main, I'm calling a function INIT()  which does a lot initializations and configurations. Somehow I can't see the implementation details. I'm not sure what is exactly done in INIT...

    Well, In my project, I'm using srio, so INIT does something to qmss, cppi....I feel that there are some conflicts between INIT and openEM init. Since srio and em dispatch can't work at the same time. INIT and em_init, the latter executed one will take effect and the other one will fail working. This is why I say my last problem is sovled, since I let em_init takes effect.

    I don't know how, how to find out what are the conflicts, what could be the possible resources that both srio and em need and once configured differently would cause a failure of them.

    This may not be a really technical problem, I'm not sure....

    Any suggestions?

    Really Thank You.

  • Ruijie,

    Both SRIO and OpenEM will need to initialize the QMSS. If you are putting two examples together that both set up the QMSS independently then there will most likely be some conflicts if you leave the code the same and call the init functions separately.

    If you have access to the initialization functions you could try to see if there are any common QMSS configurations that may be overwriting each other (PDSP firmware loading, QMSS region configuration, etc). After studying the two separate configurations you can write one single configuration function that does the needed initializations in a way that does not overlap.

    If you are able to attach the files where your initialization takes place I can take a look at them and make suggestions.

    Jason Reeder
  • Thank you Jason,

    I'll check out on my own first .

    Wish You A Merry Christmas : )

  • Ruijie,

    Happy New Year!

    Any update on the combined SRIO and OpenEM initialization attempt?

    Jason Reeder

  • Happy New Year, Jason!

    Sorry for my late reply!

    I've been busy up to something else so it was kind of suspended for a while. But now I think I should gain a better understanding about the EM demo to be more able to solve the problem.

    As I try to learn more details, I got a few questions blew, really hope you can help me with these questions Jason.

      1. There are a lot queues opened in global_init, but how many queues opened in global_init are actually used? Are those all necessery?

      2. hw queues

        Does this means pdsp can only applied to these queues? Can pdsp monitor other queues? General purpose queues?? All queues opened in em are start from 1024.

      3. The event is pushed to sdqueue by em_send as Emti_pushEvent (Emti_gvDspMcb.sdQueueBaseIdx + sdQueueIdx, (void *)event); and in dispatch_once ,event is popped from pfqueueRegDPtr. Why the event is in pfqueue while the prefetch is OFF? Where is the code that configures the pfqueue to be the receive queue?
      4. How pdsp is used in EM ? It's firmware used in EM is  em_scheduler_fw_c6678_pdsp1  what's its difference with acc48 ,acc32 and acc16.In a qmss example, there's a explicit call qmss_programAccumulator() and the arrived descriptors are popped to a list address with an interrupt to a core which generated by pdsp.While in EM, I didn't find the similar call and the arrived descriptors are manually popped by reading register

    Could you help me with these? Or some page links or pdfs that may help?

    THANK YOU SO MUCH!

    ruijie.

  • Ruijie,

    1. The short answer is yes, all of the queues opened in the init_global() function are necessary. The long answer is the OpenEM firmware requires several QMSS queues in order to operate. Most of these queues are initialized and used 'under the hood' by the firmware (some of them are necessary for the user to create and initialize).
      1. In Example_0 the user is responsible for providing the OpenEM firmware with a base queue index (hw_queue_base_idx) to tell the firmware where to start opening queues. You can specify this hw_queue_base_idx by changing the definition of MY_EM_HW_QUEUE_BASE_IDX in the my_em_init.h file of the example. Example_0 currently uses queue 1024 as the base queue and the firmware opens queues from 1024 to ~1589 depending on the number of cores and the number of priorities used. Please see the ti_em_init_global() function in the mcsdk_02_01_02_06/openem_1_0_0_2/packages/ti/runtime/openem/src/event_machine_init.c file to see how the hw_queue_base_idx value is used by the firmware.
      2.  The user must create and initialize free queues for each pool that they create
        1. Example_0 creates a general pool, an exit pool, and preload pools for each core. These pools begin at the base queue of MY_EM_FREE_QUEUE_BASE_IDX which is set to 2048
    2. The hardware queues that you are showing in this image are the queues that are monitored by the Descriptor Accumulation Firmware, not the Open Event Machine Firmware.
      1. There are different firmwares that can be loaded into the PDSPs. The Open Event Machine Firmware uses the queues mentioned above in part 1 (which are user configurable) and the Descriptor Accumulation Firmware is hardcoded to monitor the queues that you have posted in the picture under part 2.
      2. See sections 4.1, 4.2, and 4.3 of the KeyStone Architecture Multicore Navigator User's Guide for a description of the different firmwares that can be loaded into the PDSPs (http://www.ti.com/lit/pdf/sprugr9)
    3. The ability for an event to be preloaded is determined by the event type used while calling the em_alloc function. In Example_0, em_alloc for the processing events is called from the my_sourceJobs function in the my_receive.c file. The event type passed in with the original Example_0 code is MY_EM_PROC_EVENT_TYPE which is defined as TI_EM_EVENT_TYPE_PRELOAD_ON_SIZE_C in the my_em_init.h file. This means that all of the jobs that are created in the my_sourceJobs function will be preloadable. 
    4. As discussed in part 2 above, the Open Event Machine Firmware and the Descriptor Accumulation Firmware are two completely separate firmwares that can be loaded into the PDSPs.
      1. The OpenEM firmware implements a scheduler that dispatches events to cores
      2. The Accumulation firmware is meant to generate interrupts and keep cores from polling on a specific set of queues. Namely the queues that you mentioned above (0-511 and 704-735)

    Thanks,

    Jason Reeder

  • Hi Jason,

    Thank you for your reply ,it really helped me.

    Big sorry for my delayed reply !

    Our work has been temporarily suspended for a while but i'm still work on OpenEM. My problem of this post is solved somehow.I'm using PDSP2 instead of PDSP1 then the dispatcher works normally.

    Thank You!

    ruijie