AnsweredAssumed Answered

Synchronization between cores while using MDMA.

Question asked by Sumetaso on May 27, 2010
Latest reply on Jun 15, 2010 by Sumetaso

Hi all,


Has anyone seen any strange behavior from the adi_dma_MemoryCopy api?


I am running an application that uses both cores, which is synchronized by using the adi_aquire_lock and adi_release_lock functions.

 

Both adi_int_Init and adi_dma_Init have run successfully, and adi_dma_MemoryOpen runs without problems.

 

The adi_dma_MemoryCopy is used without callbacks.


No other code that modifies the SICB_IMASK* is active, and while stepping the code I see the interupt registers as correct.


But the thing that occurs is that after waiting on the adi_aquire_lock, I no longer get any calls to the interrupt service routine in the adi_int or adi_dma API's.


Both the testset_t variable are allocated within shared memory in CoreB.


So the conclusion I have reached is that : While CoreA is waiting on a lock, CoreB cannot process any interrupts in the adi_dma interfaces.


Has anyone seen any similar behaviour, or any suggestions to what I could be doing wrong?


I am using VisualDSP++ 5.0 Update 7 on a ADSP-BF561.


My scenario is the following written in pseudo code. :


CoreB

int main( void )

{

  adi_dma_MemoryCopy(); // <- Here the MDMA copy works perfect and also on the next line.

  adi_dma_MemoryCopy();


  adi_acquire_lock( core_b_begin_boot ); //Always busy at startup.


  adi_dma_MemoryCopy(); // <- Here core B "hangs", stuck at the following row : adi_dma.c : Line 1626

  adi_dma_MemoryCopy();

 

  adi_release_lock( core_b_status_ready )

}

 


Core A

int main( void )

{

     adi_core_b_enable();

     adi_release_lock(&core_b_begin_boot);

     adi_acquire_lock(&core_b_status_ready); //Always busy at startup


     //Start doing stuff.

}

Outcomes