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.

TPA3255: Unexplained 288ms delay

Part Number: TPA3255

Tool/software:

Using a modified TPA3255EVM we're seeing a 288ms delay between the nRESET line being de-asserted (driven high) and the C_START line even starting to charge (the charge is quick after that). We've reduced the DC blocking caps for all the channels from the default 10uF to 0.1uF which should reduce the pre-charge time by a factor of 100. We've validated the capacitors do charge much faster as expected. What is causing this arbitrary delay?

  • Hello,

    Are the DC caps the only modification to the EVM? Let me check on what causes this delay.

    Regards,
    Sydney Northcutt 

  • We also drive the nRST signal from a custom PCB. We also changed the clock selection between master mode, AM1 and AM2 and the delay seems to be proportional to clock speed. It seems like there may be a fixed number of clock cycles once taken out of reset. Can you confirm?

  • Hi Nathan,

    I am not sure of a fixed number of clock cycles, but since part of the start up sequence is ramping the class-d output, this make sense. The Tprecharge time is fixed to around ~200ms. This process is starting up the internal circuitry of the device as well as biasing the inputs. You may see the inputs reach steady state faster with smaller input caps, but the device is still booting up internally. The Tstartup time could be reduced by altering the C_START capacitor, but like you mentioned this is already relatively fast. 

    Regards,
    Sydney Northcutt

  • Sydney, 

    Using the TPA3255EVM the PWM switching frequency and thus clock frequency (PWMx6) can be selected via a jumper. The precharge time is only ~200ms when selecting a 600khz switching frequency. It proportionally increase to about 288ms at 450khz switching frequency. It seems to me that the precharge time is not a function of time for the DC blocking caps to stabilize but rather a fixed number of clock cycles. We actually took this a step further and provided a faster than recommended clock during the precharge time and then slow it down prior to the C_START as the FETs can't switch that fast. This speeds up the precharge as well and enables a much more rapid start. Could you check with the design group about how many clock cycles this delay for pre-charge is?

  • Hello,

    Responses will be delayed due to US Holiday. Thank you for your patience!

    Regards,
    Sydney Northcutt 

  • Hi Nathan, 

    As this is an older part that was developed roughly a decade ago, we no longer have the device designers. Based on your measurements though, this would be around 12-13k clock cycles (cycles = total time / (1/fs)). Though this results in a faster start up time, there is no validation or testing done with changing the clock on the fly or setting the clock outside of the recommended spec so we can not confirm the functionality of the device if this is done in your system.

    Regards,
    Sydney Northcutt