• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 243 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.

TPS65919-Q1: OTP=0x52: Powerhold waiting time changed?

Arseniy Platonov
Expert 1555 points
Part Number: TPS65919-Q1

Hi.

O919A152TRGZxQ1: Did something change in OTP=0x52 since last time?

User's Guide says that Powehold UP waiting time is 8sec.

The previous chips (bought by me in spring 2018) wait for 8secs.

Recently bought chips (fall of 2018) seem to have timeout for only 5sec.

Did you modify Powerhold Timeout in OTP?

  • 0
    TI__Expert 8810 points
    Senchuss,
    I am not familiar with the history of this part. I have forwarded your question to our product specialist for this IC. You should hear from her later today.

    Thank you for using E2E.
  • 0
    TI__Genius 10000 points
    Senchuss,

    Hi, we have not made any modifications to the POWERHOLD timing.

    Have you made changes to when POWERHOLD goes high, relative to VCCA?

    The POWERHOLD signal takes ~5ms to begin executing the power up sequence once pulled high. However, if you pull it high at the same time as VCCA, it can take up to 15ms. This because the device needs time to load the OTP file first. If you wait at least 10ms from VCCA going high, the POWERHOLD should consistently take ~5ms to execute the power up sequence.

    Please let me know if this answers your question.

    Thanks,
    Nastasha
  • 0 in reply to Nastasha
    Expert 1555 points
    Hi, Natasha.

    The problem is usage of latest 919/otp52 with TDA3 in context of power-management.

    I'm sorry for little big text. Let's me explain the situation. Side (A) is PMIC919/otp52. Side (B) is TDA3.
    1) Host (PC) starts and wait for TDA3(uart boot mode) answer for primary clear mount board flashing.
    2a) PMIC start all power for TDA3
    2b) TDA3 has empty mounted clear qspi-flash and needs to be flashed via uart. TDA3(uart boot mode) RBL sends ASIC_ID.
    3) The host(PC) accepts TDA3 - ASIC_ID and sends "Perepherial Boot". Then it sends binary code of CustomQspiFlashWriter.
    3b) TDA3 RBL receives code and starts execute it.
    4b) CustomQspiFlashWriter executable starts and immidiatelly UP the Powerhold signal (TDA3 gpio-pin connected to Powerhold PMIC919 pin). This is signal "I'm Alive! I'm working! Dnt powerdown me please!". Then it accept another code via uart and flash it to qspi.

    As I can understand, Your primary logic of powerhold signal is: If SOC(Tda3) is dead(malfunctional) then it can't UP Powerhold line and PMIC will powerdown this bad SOC after ... TIMEOUT interval ... Basically this is 8 seconds.

    As I explain .. The interval from (2a)PmicStartPowerForTda3 to (4b)CustomQspiFlashWriterCodeExecutable brings Up PowerHold line
    Is about 6 seconds (transmit code via uart115200 and start execution).

    Your UserGuide says about 8 seconds of waiting. It's enougt for this primary uart-qspi-flashing procedure. It works, as I can see on my board at Nov2018.
    But some days ago, we mounted new boards and it not works. Exatly in time of expected starts of CustomQspiFlasher the Pmic919 drop power down for Tda3 (possible as for Powerhold monitoring).
    Measurement time is about 5 seconds.
    Exactly. The 5 seconds is not enought to boot CustomCode via Tda3 uart and start it. This expected time is about 6 seconds.
    So. If you are changed Powerhold waiting from 8 seconds to 5 seconds - it's bad idea for TDA3 uart boot.
    If you dont chage PowerHold time waiting .. please confirm it. I'll try to check MCU companion Firmware in case that MCU can drop down powerhold line.

    Thanks in advance.
    Best regards.
  • 0 in reply to Arseniy Platonov
    TI__Genius 10000 points

    Senchuss,

    As mentioned in the previous post, the delay associated with POWERHOLD is on the order of 5-15ms, not seconds. Additionally, there is no OTP register to control this delay. We have not changed anything on this device, including silicon and programming.

    Have you measured the delays between your steps 2a and 4b? It is likely something in the middle of these steps that has extended its execution by seconds.

    Thanks,

    Nastasha