3
\$\begingroup\$

I'll start out by saying I'm a total newbie to this stuff, so I apologize if this is a silly question. For context, I'm trying to bit-bang the Low Pin Count bus using a FT232H.

Here's a timing diagram from the LPC specification:

Low Pin Count Bus Timing Diagram

Here's a logic analyzer capture of the LPC bus:

Logic Analyzer Capture of LPC bus

If I'm reading it correctly, the spec diagram shows LFRAME# and LAD[3:0] being set between the rising and falling edges of the previous clock and then sampled on the next rising edge. The LA capture, however, shows the signals changing only right at the rising clock edges. I assume that, realistically, sampling occurs shortly after the edge instead of right on it, correct?

The vultureprog programmer changes LCLK, LFRAME#, and LAD[3:0] in steps, so its waveform ends up like this:

vultureprog LPC waveform

(Transcribed from the code, as I don't have a board to test it on.)

Its similar to the spec diagram, but the signals change just before the rising clock edge instead of the previous falling one.

With the FT232H in MPSSE mode, I can produce a waveform like the one in the LA capture (that is, the signals change at the rising edge and hold until the next rising edge). When I run that through Sigrok's LPC protocol decoder, it doesn't sample the expected values for the Start or CT/DIR fields and the rest of the cycle is thrown off. Looking at the decoder's code, though, there are some issues like the TAR field being out of order for write cycles. It seems the original author didn't test it very extensively.

So is the protocol decoder wrong or am I misunderstanding how digital logic works and not changing my signals at the right time?

\$\endgroup\$
  • 2
    \$\begingroup\$ The LPC spec looks pretty big so I have not read it, but usually these specs will have a Setup and Hold time relative to the clock. If Setup = 1 nS, Hold = 3 nS, then before the active clock edge you need your data lines at the right level 1 nS before the edge, and 3 nS after. The logic analyzer samples everything on its own clock, so it won't pick up that level of shift. FYI, It looks like LPC is related to PCI, which samples data on the rising edge of the clock. \$\endgroup\$ – pscheidler May 1 '18 at 17:22
  • \$\begingroup\$ @pscheidler Yes, I hadn't considered the difference between LCLK and the logic analyzer's clock. Thanks for the info about setup and hold times. The LPC spec doesn't mention them, but defers to the PCI spec for specific timings. \$\endgroup\$ – David Brown May 1 '18 at 18:53
0
\$\begingroup\$

Logic analyzer (as shown) clearly samples/interprets data on the falling edge of CLK. However, LPC specs never mention clock edge, only refers as "first clock", "second clock", etc. How silly. But again, Figures 5 and 6 in LPC specs suggest that data bus changes around rising edge, and sampling (data evaluation) goes on falling edges.

enter image description here

There is no timing presented the the entire LPC specs, only a reference to PCI spec 2.3.

Given these uncertainties, the programmer still looks logically/formally correct, but I suspect that the logic analyzer gets confused with the long delay between LAD to pos-edge_CLK. You might need to tweak the logic analyzer sampling conditions or rates.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.