Coherency Unit and DMA in MPC5675K

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Coherency Unit and DMA in MPC5675K

830 Views
JChMathae
Contributor II

Hello,

 

 

We have developed a software on an MPC5675K which works quite well when only one e200 core (the first) is active:

  •   both CTU units triggers at 10kHz the four ADC units, which write in two CTU FIFO, in turn emptied into SRAM by both DMA controllers
  •   the Coherency Unit and the DMA are configured to update the first core data cache

 

But when the MMU and data cache of the second core are configured together with the Coherency Unit - even when the second core execution is suspended by a "wait" instruction - the DADDR field of one of the DMA channels increments by the value of the its DOFF field every few minutes, slowly corrupting the SRAM as a consequence.

As if one DMA transfer was aborted and retried every now and then, but without first restoring the DADDR field to its previous value...

 

Any idea?

 

Best regards.

 

 

Jean-Christophe

Labels (1)
0 Kudos
3 Replies

624 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

I don't understand this explanation too much. Could you explain your issue more in detail? Do you have properly set coherency unit (for both cores and both DMAs)? Have you set global write indicator (DMAGPOR register) as global for particular channels?

0 Kudos

624 Views
JChMathae
Contributor II

David,

Yesterday after noon I had time to experiment a little more.

First I recompiled my program with full optimization. It seems that enables the program to run inside DCache only, as the updates of my variable shared between the two cores was not propagated between the writing core and the reading core. Indeed I used "write-back" strategy for the DCache stores. I also got not DMA "bug".

Then I switched to the "write -through" strategy, and now I get a torrent of bugs!

0 Kudos

624 Views
JChMathae
Contributor II

David,

Thank you for your help!

Yes, I think I have properly set CU/MMU/DCache/DMA registers, at least for the first core, as my first core DCache is updated when the DMA writes in SRAM. I have checked, for instance, that without proper DMAGPOR settings the core does not "see" the SRAM update by the DMA stream.

My "explanation" is rather intuitive and only descriptive and by no mean an understanding of an actual mechanism.

All that I can say for sure is that activating the DCache for the second core with corresponding CU registers trigger the "bug".

I can provide source files or register snapshots if you like...

Best regards.

Jean-Christophe

0 Kudos