• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 427 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.

ISO7421E minimum pulse width

marco sartor
Prodigy 80 points
Other Parts Discussed in Thread: ISO7421E

Folks, What happens to the output of the ISO7421E if it receives an input pulse less than the minimum input pulse width (Tui 20 ns) stated in the data sheet on page 3? Regards, Marco

  • 0
    TI__Genius 14015 points

    Hi Marco,

    The ISO7421E will most likely operate normally up to about 100 Mbps (tui of 10 ns). We haven't characterized the part to that level, so we can't guarantee performance at that speed. That's why we claim 50 Mbps in the datasheet. If you started getting down to pulses of about 5 ns, then there could start to become issues such as latch up, where the part only recognizes the rising edge but misses the falling edge. That could cause the output to stay at a high or low until the DC refresh occurs, which could be about a 6 us delay.

    I hope this helps answer your question.

    Thanks!
    Jason Blackman 

  • 0 in reply to Jason Blackman
    Prodigy 80 points

    Hi Jason,

    this is a bad carachteristic... why a 150mps device refresh every 6uS? I think a right refresh time could be 200nS

  • 0 in reply to marco sartor
    TI__Genius 14015 points

    Hi Marco,

    When there is an input pulse short enough that the part detects the rising edge but misses the falling edge (assuming a low-high-low pulse) there is a glitch and the output will latch high. If there is another pulse after this that has a falling edge, the part will detect that and correct itself. There would be several bit errors in this case. If there is no pulse following the glitch, then it will take about 6us as mentioned previously, as there is no falling edge for the part to detect and correct itself with.

    Does this help answer your question?

    Thanks,
    Jason Blackman 

  • 0 in reply to Jason Blackman
    Prodigy 80 points

    Hi Jason,

    the device is indicated for use in DeviceNet, what happens if a glitch due to collision messages appear ? Will generate an error frame ? Is correct ?

  • 0 in reply to marco sartor
    TI__Genius 14015 points

    Hi Marco,

    I apologize for the delay. In CAN there shouldn't be any glitches due to collisions. Priority addressing is used such that if two nodes start talking at the same time, whichever node has more dominant bits in the address will keep talking and the lower priority node will go recessive and hear that another node is transmitting.

    For example, if two nodes start transmitting at the same time and Node 1 has an address of 100 and Node 2 has an address of 101, they will both transmit "10" without knowing that anyone else is trying to use the bus, then on the third bit Node 1 will hold the line dominant while Node 2 goes recessive, and Node 2 will see that someone else with higher priority is transmitting and back off.

    Let me know if you have any more questions, or if you meant something else.

    Thanks,
    Jason Blackman