cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
2,585 Views
Registered: ‎04-19-2010

NPI RdFIFO_Data Zero & PPC

Jump to solution

I ran into a problem last night, which took my night; thought this would be useful for some one in future. So posting it here for somebody who run into similar problem.

 

I was a merging my 64bit NPI module which was developed in a simple EDK project[PPC, MPMC(DDR2), etc]. The PPC software was derived from simple example project of SDK. Everything was working fine in my project. The data is populated over PPC440MC0 interface by PPC software.

 

But all starting going bad when I merged this peripheral with our legacy code which had similar EDK project but lots of other peripherals too. The PPC software for this came from legacy(ISE11.x) SDK examples based one, and was customized a lot for the application. The problem is that NPI read always returned zero, though all other signaling was perfect. Though I was able to write/verify the same memory location directly from PPC440MC0 interface.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
3,270 Views
Registered: ‎04-19-2010
After a long fight with the code, I found that legacy PPC software has DATA CACHE enabled for MPMC address range regions. This caused data populated by PPC software not yet flushed to DDR. So the NPI reads always read unsynchronized memory locations.
I identified this problem out of luck actually. During debugging, the PPC software send wrong protocol data to the peripheral, which caused it to read from random high range location, which was filled with garbage. This random data read on NPI gave me confidence that NPI-MPMC is actually working and no configuration problem. By now I realized some locations are read properly, it immediately clicked that this is a caching problem. I checked through the large PPC legacy software code, and first two lines of entry point were enabling the cache.

So much relieved now.

View solution in original post

0 Kudos
2 Replies
Highlighted
Observer
Observer
3,271 Views
Registered: ‎04-19-2010
After a long fight with the code, I found that legacy PPC software has DATA CACHE enabled for MPMC address range regions. This caused data populated by PPC software not yet flushed to DDR. So the NPI reads always read unsynchronized memory locations.
I identified this problem out of luck actually. During debugging, the PPC software send wrong protocol data to the peripheral, which caused it to read from random high range location, which was filled with garbage. This random data read on NPI gave me confidence that NPI-MPMC is actually working and no configuration problem. By now I realized some locations are read properly, it immediately clicked that this is a caching problem. I checked through the large PPC legacy software code, and first two lines of entry point were enabling the cache.

So much relieved now.

View solution in original post

0 Kudos
Highlighted
Anonymous
Not applicable
2,579 Views

Hi,

This exact problem has caught me many times over.  One call to XCache_EnableDCache() can really wreck your week :).

 

Glad you got it solved.

 

0 Kudos