2008-11-04 20:42:21     BF54x : Read over PPI loses upper 8-bits

Document created by Aaronwu Employee on Aug 8, 2013
Version 1Show Document
  • View in full screen mode

2008-11-04 20:42:21     BF54x : Read over PPI loses upper 8-bits

Isaac Leung (CANADA)

Message: 64672   

 

We modified the existing PPI driver to work with our board using BF548.

 

So far we can verify that the PPI WRITE operation is happening. However, when we attempt a PPI READ operation, we seem to lose the stuff above 8-bits.

 

We are strictly using EPPI1, which, if I recall, should be limited to 16-bits maximum. It shouldn't be a matter of variable type (i.e. 8-bit vs. 16-bit) because we're using the same one for all sorts of other operations, including the PPI WRITE and it's okay. We've been debugging the driver and we can see that within the driver ppi_read() operation itself, it has somehow lost the upper 8-bits after the DMA has finished.

 

We can read back the PPI config register and it is set like we want it to and we've had another party confirm that 16-bit reads occur when using that configuration under VisualDSP++ for the same chip.

 

Anyone have any ideas where we can start looking as to how the 8-bits somehow got lost? We do try to observe the data in memory right after the DMA is completed (not sure what sort of activity happens between when DMA finishes and when we "look"), but it seems even then, the memory isn't populated correctly, just the lowest 8-bits.

 

The driver would appear to have been built to handle more than 8-bits data, and the write works fine. The code itself is pretty much the same as the BF5xx PPI driver included in the usual source, but just modified to use EPPI1. We are only doing 1D transfer, and it is in a GP 1 with internal FS and clocks, not using any 2D or ITU modes.

 

 

 

 

 

Thanks,

 

Isaac

QuoteReplyEditDelete

 

 

2008-11-05 07:28:31     Re: BF54x : Read over PPI loses upper 8-bits

Robin Getz (UNITED STATES)

Message: 64699   

 

Isacc:

 

It is pretty difficult to debug your custom driver without seeing the source.

 

Can you attach a diff from the existing driver?

 

-Robin

QuoteReplyEditDelete

 

 

2008-11-05 12:12:30     Re: BF54x : Read over PPI loses upper 8-bits

Isaac Leung (CANADA)

Message: 64706   

 

I've attached the diff between the existing "bfin_ppi.c" and our current code

 

(BTW, I'm not expecting you to debug it for me, I'm just wondering if anyone has actually tried 16-bit reads or if there's some "obvious", common error that we might be making)

 

Everything else works with this driver, we think. PPI Write is fine and we can PPI Read 8-bits at a time, so we currently have worked around that temporarily so that we can progress with other stuff.

 

 

 

Isaac

 

diff.txt

QuoteReplyEditDelete

 

 

2008-11-05 16:10:47     Re: BF54x : Read over PPI loses upper 8-bits

Frank Van Hooft (CANADA)

Message: 64712   

 

As a random thought, did you check the contents of the PORT_MUX register during your PPI read to make sure you don't have a pin muxing problem?

QuoteReplyEditDelete

 

 

2008-11-05 19:19:08     Re: BF54x : Read over PPI loses upper 8-bits

Isaac Leung (CANADA)

Message: 64718   

 

Yes, that's set. We're pretty sure about that because that actually caught us out once.

 

But thanks, now that you mentioned it, I've got an idea where to look now ... port dir mask might be wrong...

QuoteReplyEditDelete

 

 

2008-11-06 02:46:18     Re: BF54x : Read over PPI loses upper 8-bits

Mike Frysinger (UNITED STATES)

Message: 64732   

 

you arent touching the port mux registers directly are you ?  there is a peripheral framework which should do all of that for you.

QuoteReplyEditDelete

 

 

2008-11-07 13:25:06     Re: BF54x : Read over PPI loses upper 8-bits

Isaac Leung (CANADA)

Message: 64849   

 

We are controlling the port muxing ourselves within the PPI driver, using functions such as "bfin_write_PORTD_MUX()"

 

The documentation at:

 

http://docs.blackfin.uclinux.org/doku.php?id=ppi

 

says we need to be careful to handle that sort of stuff ourselves. Is this not correct?

QuoteReplyEditDelete

 

 

2008-11-07 13:50:27     Re: BF54x : Read over PPI loses upper 8-bits

Mike Frysinger (UNITED STATES)

Message: 64850   

 

that documentation is talking about the PPI registers (in fact, it explicitly lists the registers it refers to).  PORT_MUX registers are not PPI registers.  we have a peripheral framework (which the PPI driver in our tree uses) which handles this stuff for you.  you should not be touching any PORT_MUX register yourself.

 

so unless i missed something, the documentation does not say you should touch any PORT_MUX register ... if it anywhere in our docs or source it does, please point it out so we can get it fixed up ...

QuoteReplyEditDelete

 

 

2008-11-07 14:21:56     Re: BF54x : Read over PPI loses upper 8-bits

Isaac Leung (CANADA)

Message: 64852   

 

Hmm... maybe I am misunderstanding it, but a section in that page says:

 

"No framework or API exists to help with controlling the PPI, so you will be spending a lot of time reading/writing directly to the PPI's MMR registers. Note that this also includes making sure you handle the port muxing aspects that some versions (like the BF537) utilize in mixing GPIOs with PPI pins."

 

In fact, we ran into this very problem where some of the FrameSync pins were not selected for their proper operation. It was taken over by the default GPIO functionality instead so we had to explicitly enable the PPI function.

 

Could you please point me to the peripheral or port mux framework you're referring to? I couldn't find it on the Blackfin Linux Docs website.

QuoteReplyEditDelete

 

 

2008-11-07 14:31:27     Re: BF54x : Read over PPI loses upper 8-bits

Mike Frysinger (UNITED STATES)

Message: 64855   

 

thanks, ive updated that section

 

the ppi driver should already be using it.  look for things like peripheral_request*() and peripheral_free*() ... otherwise there is just the portmux.h header file.

 

ill have to write a wiki page with more info and/or kernel-doc the portmux header ...

Attachments

Outcomes