• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 420 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.

SN65LV1023A: Transmitted data pattern that seems to break SN65LV1224B PLL

Kyle Andersen1
Prodigy 50 points
Part Number: SN65LV1023A
Other Parts Discussed in Thread: SN65LV1224B,

Hello,

We have been performing bench testing on the SN65LV1023A and SN65LV1224B SerDes LVDS transceiver pair for a long time now. We have hundreds of hours of testing with 0 error transmission between these devices. I only say this in advance to re-assure that our TCLK and REFCLK tolerances are good, electrical connection between the devices is good, etc.

We seem to have found a specific data pattern that trips up the PLL of the SN65LV1224B after it has already achieved lock through the 1026 transmissions synchronisation pattern sent from the SN651023A. The table below shows the specific sequence. The !LOCK signal seems to go high around data payload 7 or 8. Our suspicion is that the combination of 0x100 + 0x1FF + 0x1FF + 0x1FF + 0x1FF + 0x100 is causing the issue. There are many times when we send hundreds of 0x100 or hundreds of 0x1FF with no problems.

Description 

Packet that breaks 

Packets that work 

Wait time after EN for PLL stabilization 

 

 

1026 bytes sync pattern 

1 + 0x3E0 + 0 

1 + 0x3E0 + 0 

Fake payloads for DMA alignment 

0x100 (numerous transmissions) 

0x100 (numerous transmissions) 

 

Data Payload 0 

0x1EB 

0x1EB 

Data Payload 1 

0x190 

0x190 

Data Payload 2 

0x108 

0x108 

Data Payload 3 

0x100 

0x100 

Data Payload 4 

0x1FF 

Anything other than 0xFF 

Data Payload 5 

0x1FF 

Anything other than 0xFF 

Data Payload 6 

0x1FF 

0x1FF 

Data Payload 7 

0x1FF 

0x1FF 

Data Payload 8 

0x100 

0x100 

Data Payload 9 

0x101 

0x101 

Data Payload 10 

0x100 

0x100 

Data Payload 11 

0x100 

0x100 

Data Payload 12 

0x1CE 

0x1CE 

Fake payloads to fill a full packet structure that we use 

0x100 (numerous transmissions) 

0x100 (numerous transmissions) 

 

Have you observed this type of behaviour in the SN65LV1224B before?

Thank you in advance and kind regards,

Kyle

  • 0
    TI__Mastermind 22930 points

    Hello Kyle,

    Our team has not observed this type of behavior before and are unsure why this specific pattern has issues. 

    We will continue to look over this but for the meantime we recommend avoiding this pattern.

    Regards,

    Josh

  • 0 in reply to Joshua Salinas
    Prodigy 50 points

    Thank you for the reply Joshua,

    To add some more contextual information:

    • We see the !LOCK signal go high about 1/100 times with the data pattern I described in the original post.
    • TCLK = REFCLK = 10.51 MHz
    • The system is in a multidrop configuration where a single SN65LV1224B is connected to multiple SN65LV1023As over Cat5e cable. Only 1 transmitter at a time will power on (!PWDN / EN), wait for PLL to stabilize, send the SYNC pattern (!LOCK signal always go LOW), send a cushion packet (for processor DMA alignment), send the data packet, and then power down for the next transmitter's turn.

    Is there any more detail you have about the PLL in the SN65LV1224B other than the datasheet statement?:
    "The deserializer stays in lock until it cannot detect the same data boundary (stop/start bits) for four consecutive cycles."

    We are wondering in what situations the SN65LV1224B PLL will lose lock and bring the !LOCK signal high. The datasheet makes it clear that the RMT patterns will only increase the locking time but not impact the deserializer state. So it seems strange that the data pattern might create a situation that makes it difficult for the deserializer to detect the START and STOP bit precisely.

  • 0 in reply to Kyle Andersen1
    TI__Mastermind 22930 points

    Hello Kyle,

    My guess is the RTM pattern you mentioned could be the issue. Having a consecutive pattern [01010..] on the serializer input should be fine. But having two consecutive inputs like D0,D1 or D4,D5 with 01010.. could cause issues and prevent the deserializer from locking. However in your previous post you mentioned this only happens 1/100 times with the same data pattern.

    If the RTM pattern was really the issue, I would think you would see unlocking more often.

    Regards,

    Josh

  • 0 in reply to Joshua Salinas
    Prodigy 50 points

    Hello Joshua,

    It's tempting to think that the RMT patterns might have something to do with it. My only hesitation is that the datasheet specifically says "Notice that the RMT pattern only affects the deserializer lock time, and once the deserializer is in lock, the RMT pattern does not affect the deserializer state as long as the same data boundary happens each cycle."

    Many other transmission tests we have 100% success on, so that means our TCLK and REFCLK signals must be of good enough quality. So, I don't want to believe that the data pattern creates the situation where the deserializer cannot determine the data boundary.

    Kind regards,

  • 0 in reply to Kyle Andersen1
    TI__Mastermind 22930 points

    Hello Kyle,

    Usually the clock tolerance is the number one issue with these devices. We see it all the time. 

    But, I also don't think it's the TCLK and RECLK clock tolerances since you've ran other transmission tests without any issues.

    Regards,

    Josh