SN65DPHY440SS: Seems to be stuck in LP mode

Chris

After RSTN = H, you should hold interface in LP11 for at least 100us before switching to HS.

Are you using lane 0 as the data lane?

Thanks

David

Yes, I'm using lane 0. When it works, it works well.

So the data lane should be in LP11 when the repeater comes out of reset, yes? That's important because my MIPI source is an FPGA which takes a few seconds to initialise, and the data lane is definitely not in LP11 state before it's initialised.

Chris

David, thank you very much for the detailed reply. That explains a lot, including why it works sometimes but appears to be very dependent on the startup sequence of the various components. We don't have I2C access to the chip at the moment but I can see various ways ahead. I can probably force the FPGA's data line into LP state for a while at startup or, if that turns out to be difficult, use another lane. I can probably try that out with mod wire quite easily.

Chris

Chris,

Sounds good, please let me know your progress and if any additional support is needed.

Thanks

David

I've just tried using lane 1 instead of lane 0, but with no success. The configuration is: lane 0 open, lane 1 MIPI data, lanes 2 and 3 grounded. Usually after reset the lane 0 inputs go up to about 500mV and stay there, and lane 1 passes only the LP data from the MIPI stream, and the clock output is inactive. So it seems that the symptoms are the same when I use lane 1.

I'll try taking lane 0 to LP11 briefly and see if it wakes up the chip.

Chris

Chris

On the clock lane, do you see clock lane go to LP11 (1.2V) after RST is high and stay in LP11 for at least 100us?

Thanks

David 

You mean the clock lane input to the SN65DPHY440? No, I don't think I do. I have established that the FPGA's PHY wants separate pins (paralleled externally) for the LP and HS signals, but we don't have the LP ones mapped out so everything takes place in HS mode. The best I can do in the FPGA is disable the HS mode drivers.

I will look at the clock lane signals at startup and see what they're really doing, but I suspect they're not going to be going to LP11.

Chris

I've just looked at the clock lane at startup. After reset is complete, both signals are at 0V because the FPGA hasn't yet been initialised. Once the FPGA has started up, the clock lane goes to LP11 for 14us, then clock+ goes low, then about 100ns later clock- goes low, then about 100ns later both of them clearly go in to HS mode and another 500ns later the clock starts.

Chris

Is this a working case or a non-working case? 

If you are using a passive circuit on the DPHY440 RSTn, is it possible to change the pulldown capacitor on the RSTn to hold the DPHY440 in reset longer until the FPGA finishes its initialization and drive LP11 on both the data and clock lane.

Thanks

David

This was a non-working case. I have now had chance to modify the FPGA firmware so that it holds the data lane in LP11 state for 250us when it starts up, and now the repeater works even though it comes out of reset long before the FPGA is initialised. I haven't yet tested this on data lane 0 - my test rig is still wired to lane 1. I don't have access to rework facilities to put it back on lane 0 at the moment but I hope the same fix will work on lane 0.

Thank you for pointing out that LP11 must be maintained for at least 100us. It does seem to have fixed the problem. If it also works on lane 0, then we won't need to make any hardware changes which is very welcome.

Chris

Chris

Thanks for the update, please keep in the mind the special requirement on lane 0 being a bi-directional lane.

David