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.

TPS65950 Keeps Asserting nRESPWRON

Other Parts Discussed in Thread: TPS65950

We have a new board we are bringing up, and it keeps resetting itself.  The reset behavior is somewhat board dependent, but all boards are resetting themselves, as best we can tell by asserting the nRESPWRON signal.  While the nRESPWRON signal is not asserted all the voltages seem good.

One board typically would assert nRESPWRON when it jumped to U-Boot from X-Loader, or from U-Boot to Linux, or part way through decompressing Linux.  At power up this board would reset itself each time it tried to begin executing U-Boot.  Over about a minute it would start into executing U-Boot, and eventually completely run U-Boot without resetting.  In other words, it got more stable the longer it was turned on.  After a while it seemed fairly stable and we could do some U-Boot testing, and NAND writing, etc.

Another board keeps asserting nRESPWRON about every 100 ms.  We can't program X-Loader or U-Boot to this board because of the resets.

Another board seems to assert nRESWARM every 7ms for about 800ms, then it stops for 500ms, then starts again with the 7ms nRESWARM assertions.  When we try to download U-Boot to it over UART3 the nRESWARM resets stop while downloading, but at the end of the download process nRESPWRON is asserted and we fail to execute the just-downloaded U-Boot.

Any suggestions as to what might be causing the TPS65950 to assert nRESPWRON?

Any suggestions as to what might be causing nRESWARM to be asserted with that strange pattern?

 

Thanks in advance,

 

Chris

  • I believe I understand what the 7ms warm reset is--it's the boot sequence: USB / UART3 / MMC1 / NAND, but there's nothing in the NAND yet, so it just keeps repeating, looking for something to boot from.

  • Hi Chris,

    We have seen such instances. Have you figured out the reason, you did mention that the NAND is empty?

    Do you still see the problem?

     

    Regards,

    Gandhar.

     

  • The NAND was empty for the 7ms reset case.

    The nRESPWRON problem turned out to be that we didn't have a battery in the circuit--the VBAT voltage was drooping and causing the nRESPWRON signal to get asserted.  The reason we saw two different behaviors for that case is because the two different boards had a significant difference in the amount of capacitance on the VBAT line, so it didn't drop so readily.