• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 303 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.

TMS320C6654: TMS320C6654CZHA8 BOOTCOMPLETE

Ramgopal Divakar
Expert 1300 points
Part Number: TMS320C6654
Other Parts Discussed in Thread: TMS320C6655, TMS320C6652

Hello,

we have used this DSP over several designs. On a new design we are trying to debug the DSP in some situations getting stuck where BOOTCOMPLETE signal is at 0 and not 1. We are following the IO before core sequencing circuit in your datasheet. After the power stablizes and clocks are assweted we always deassert RESET, PORn, and RESETFULLn in that sequence.

Reset is deasserted first, then 2 ms later POR and then 100 uS later RESETFULL

We follow this logic on a a power up or if our microprocessor wants to reset the DSP. We then load the IBL via the I2C EEPROM. This resetting mechanim has worked over several designs.

We recently noticed that If we reset the DSP in the middle of the I2C transaction, during IBL transfer, it does not recover and BOOTCOMPLETE is always at 0. Only way to recover is a power cycle. First of all we are trying to understand why this is the case. We cannot rely on a power cycle and would like to fix this.

Thanks,

Divakar

  • 0
    TI__Mastermind 25535 points

    Divakar,

    Please do check whether you are falling into cases like below.

    Please check other advisories too regarding RESET and power hang in the data sheet.

    Usage Note 5     I 2C Bus Hang After Master Reset Usage Note

    Revision(s) Affected: 1.0

    Details:

    It is generally known that the I 2C bus can hang if an I 2C master is removed from the bus in the middle of a data read. This can occur because the I 2C protocol does not mandate a minimum clock rate. Therefore, if a master is reset in the middle of a read while a slave is driving the data line low, the slave will continue driving the data line low while it waits for the next clock edge. This prevents bus masters from initiating transfers. If this condition is detected, the following three steps will clear the bus hang condition: 1. An I 2C master must generate up to 9 clock cycles. 2. After each clock cycle, the data pin must be observed to determine whether it has gone high while the clock is high. 3. As soon as the data pin is observed high, the master can initiate a start condition.

    ---

    Usage Note 6  POR and RESETFULL Sequence Usage Note

    Revision(s) Affected: 1.0

    Details:

    For boot configuration pins to be latched correctly, during the power sequencing and reset control for chip initialization, RESETFULL must be held low for a period after the rising edge of POR but may be held low for longer periods if necessary. The configuration bits shared with the GPIO pins will be latched on the rising edge of RESETFULL and must meet the setup and hold times. Timing requirements are specified in the device-specific data manual, TMS320C6655/57 Multicore Fixed and Floating-Point Digital Signal Processor, TMS320C6652/54 Multicore Fixed and FloatingPoint Digital Signal Processor.

    -----

    Regards

    Shankari G

  • 0 in reply to Shankari G
    Expert 1300 points

    Thank you,

    our sequence on power up or when microprocessor asserts the reset to the DSP, the 3 resets to the DSP are as follows.

    (After power has stablized, clocks are provided to the DSP). On a softreset (from microprocessor), power and clocks are stable.

    Reset pin is deasserted first, then 2 ms later PORm and then 100 uS later RESETFULL when configuration bits are asserted, and 100 uS later the configuration bits are deasserted.

    Is this okay?

    It could be that the I2C EEPROM SDA line is stuck at '0' when the DSP is reset in the middle of the I2C transaciton on power which takes about 13 seconds. I am investigating further. 

    Thanks,

    Divakar

  • 0 in reply to Ramgopal Divakar
    TI__Mastermind 25535 points

    Divakar,

    To further answer your query, looping in our hardware expert too.

    More over, every advisory I pointed above has a work around. Have a look at that too.

    Regards

    Shankari G

  • 0 in reply to Shankari G
    TI__Guru 54352 points

    Divakar,

    > Reset pin is deasserted first, then 2 ms later PORm and then 100 uS later RESETFULL when configuration bits are asserted, and 100 uS later the configuration bits are deasserted.

    Can you confirm that all power rails are fully ramped before PORz is deasseted?  Also, can you confirm that RESETSTATz is deserted after RESETFULL deassert?

    Also, as a debug step you might consider delaying the RESETFULL for a longer duration before deserting. 

    From the feedback above, the I2C hang seems the most likely.

    Thanks,
    Kyle

  • 0 in reply to kcastille
    Expert 1300 points

    POR is deasserted only after power has stabilized. 

    Yes, RESETSTATz is deserted after RESETFULL deassert?

    Yes, we confirmed a double reset condition during an I2C transaction that bricked it. Thanks for identifying it and also suggesting the workarounds. We shall try it.

    Divakar

  • 0 in reply to Ramgopal Divakar
    TI__Mastermind 25535 points

    Divakar,

    Try the work around and let us know how it goes for you.

    Shall we close the thread as of now?

    Regards

    Shankari G