• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 19 subscribers
  • Views 229 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

SN74HC595: when cascade two part SN74HC595 , the secord part has some randomly error in some bit

Gene Qiu
Intellectual 1720 points
Part Number: SN74HC595

Hi Team

when degugging SN74HC595, cascade connection, the secord part has some randomly error in some bit. I am suspecting the QH' and SRCLK，

The rising edge of the 9th SCRLK will send the QH' pin value (@8th SCRLK) to the second part SER pin, meanwhile it will update the first sn74hc595

 QH 'pin value.  If QH' update earlier than the QH' sent to second part SER input, then the second part would be error.

Am i understanding right?  Is the QH' falling edge would be later than 9th SRCLK rising?  Is there any way or hint for me to measure and test to make it more clarified to show what parameter?  

  • 0
    TI__Guru* 96591 points

    Hello,

    Can you share your schematic?

  • 0 in reply to Emrys Maier
    TI__Intellectual 1720 points

    Hi Maier

    Pls see below. 

  • +1 in reply to Gene Qiu
    TI__Guru* 96591 points

    Thanks for the schematic,

    QH' is a direct output from the internal shift register H, as shown in the block diagram in the datasheet:

    When cascading devices it's best to clock all devices at the same time. If this is not possible (ie if the clock and two devices are physically separated) then the last device in the chain should be clocked first (U4) to prevent errors. This allows the last device to load in all registers first (including the output from the first device), then the new data is loaded into the first device.

    I don't see any problems with your connections here. The most likely issue would be a delay between U3 and U4 SRCLK triggers.  If the two devices are physically separated by a significant distance, this could cause errors in the data. Relatively heavy capacitive loads can also cause trouble.

    Another common source of errors is slow input transitions on the SRCLK input -- can you get a scope shot of the clock inputs to both devices? Preferably on a 100ns/div scale or smaller

  • 0 in reply to Emrys Maier
    TI__Intellectual 1720 points

    Hi Maier

    Thank you for the detailed explaination. I went to customer onsite debug, and found the SRCLK are slow and mixed with QH' edge, which may cause mis-update of QH'. After  reduce the capacitor during the Clock path, the QH' would be separate with SRCLK edge, then the failure disppeared.

    Just as you mentioned right now, " If the two devices are physically separated by a significant distance, this could cause errors in the data. Relatively heavy capacitive loads can also cause trouble"

    Thank you again for the help.

    Best Regards

    Gene