Hello,
We have developed a software on an MPC5675K which works quite well when only one e200 core (the first) is active:
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
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?
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!
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