• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 1166 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN65DSI86 bringup over DSI interface

hamasaki1818
Intellectual 370 points
Other Parts Discussed in Thread: SN65DSI86

Hello,

We got SN65DSI86 (-Q1 version for prototyping) on a test board. Did not hookup I2C (as this was intended), and wanted to configure it strictly over DSI channel.

At first, the board was strapped for 27MHz crystal - and watching DSIA_RX0 with a scope gives the following:

pic1: zoomed into transmission, to see bit time. 146ns.

pic2: zoomed into reply from DSI86, to see bit time. 148ns.

However, the DSI host is not seeing reply - It is actually seeing DSI return packet 0x11, I think, but the data fifo returns empty. Below pic is entire exchange.

So, the question is:

Is this working? Is the problem on my DSI host end?

The transaction looks ok, is 2ns difference in bit width going to  affect reception?

On the DSI host I don't have a lot of granularity for setting transmission timing - there is 'LPTIME' parameter which is currently set to '6' in order to get the 146ns-wide bits. Setting it to 5 gets me 124ns wide bits, and 7 gives me 167ns.

If this 2ns @27MHz timing is not accurate enough, is there something I can blindly write into the DSI86 registers (over DSI) to switch it into clocking from DSIACLK or similar? Or is there something else I'm misisng for the setup.

The Short read (0x24) and its arguments are correct (well, I'm reading register 00, and expecting to get back 0x20).

This is the first command I'm sending to DSI86, after deasserting Enable pin. Communication is in LP mode, using DSIA_RX0.

edit: After, the board got strapped for 19.2MHz refclk, and with that, the bit width in rx/tx is even more different, so we'll probably go back to 27MHz unless instructed otherwise. The DSI host is running from 19.2MHz refclk.

  • 0
    TI__Mastermind 18655 points

    Hello,

    Please, take a look at the link below. Could you share more details about your design? The DSIX6 will respond with either an acknowledge when the  DSI host completes transmission, if no errors were detected in current or previous packets, or an acknowledge and error report packet.

  • 0 in reply to Joel Jimenez0
    Intellectual 370 points
    Hiya,

    Yes, I've seen that document.
    The scope screenshots in first post are "LP Data Transmission" as in figure 32 in the PDF you linked.

    Because of slightly different voltage levels between send and receive, I believe DSI86 is replying, and sending different data (i.e. reading addr 0 or 3) returns different bits in reply as tested by the limit mask on scope, so I think the DSI host is just not properly interpreting the reply either due to

    1) not supporting 0x11 short reply

    2) the ~2-3ns timing difference in 27MHz oscillator mode is messing up reply reception.

    What do you think?

    As for the 'more details about design', we're trying to replace a Toshiba part (TC358770) with the similar functionality due to it being unavailable and too expensive with the TI part. So, a test board was made with SN65DSI86 on it to see if it can be used.
  • 0 in reply to hamasaki1818
    Intellectual 370 points
    So any idea? Meanwhile getting the board remade with I2C connected but still would like to not involve that if necessary...
  • 0 in reply to hamasaki1818
    TI__Mastermind 18655 points
    I don't think that 2ns affects the reception but you can try to use the MIPI DACP/C as clock source by setting the PPLL_CLK_SRC pin high and configuring GPIO[3:1] to value that matches the DACP/N frequency (Refer to Table 1 of device datasheet). Assert EN before performing a write/read request.

    Your scope capture (LP Data Transmission) shows how the data lane enters to escape mode, but the arguments for a Generic Read Request are not clear. Could you point out the read transaction and the DSI86 response IDs?

    Regards,
    Joel