We have a custom board built with T4240 processor. During power on sequence, hreset is not released by 4240 and also not able to connect to the processor through JTAG. We observed from I2C bus, 4240 is reading RCW of 74 Bytes and stops. 4 preamble + 4 (acs,length,cont=1)+ 64 rcw + 4 (acs,length,cont=0) + 4 crc makes total of 80 bytes. But 4240 reads only 74 bytes and hangs. Not even responding to JTAG. We checked clock and voltages are fine, por assertion time and hold time are verified. What could be the issue.
Thanks for your prompt response.
SYSCLK of 66.66 MHz and DDRCLK of 133.33 MHz is provided to processor and observed the clock are stable during read and after it. Serdes CLK1 is 156.25 MHz and CLK2 is not used. Serdes 2,3,4 CLK1&2 clocks are 100 MHz and are utilized.
HRESET_B held low by the 4240.
RESET_REQ_B is high.It is not connected to PORESET or HRESET_B in cpld.
ASLEEP signal is always high.
Attachment1: RCW Binary
Attachment2: RCW capture during read by 4240 through I2C Analyzer.
We powered down serdes 2 and 3 pll in RCW as you suggested. There is no change in the behavior, t4240 is holding the HRESET low.
We tried with hard-coded RCW option. The problem remains same.
Noticed the following behavior for ASLEEP.
After releasing PORESET, ASLEEP is sampled high for 820 microsecs and goes low for 39 millisecs. Later ASLEEP goes high.
ASLEEP is pulled up on our board.
Other than RCW, what could be the case for HRESET_B in continuous asserted state.
All clocks and voltage rail looks stable. PORESET_B is released after all voltages are stable.
It is required to ensure that the processor is connected and powered as recommended and required in the Design Checklist.
Ensure (check by a scope) that all notes after the Table 1. Pinout list by bus in the QorIQ T4240 Data Sheet are fulfilled - pay special attention to the signals having note 5.
Thanks for your support. Your suggestion helped us to debug deeper.
We found SVDD rail does not fully ramped up after releasing PORESET. The correction allowed proper HRESET de assertion.
The RCW seems to be incorrect.
1) What are frequencies of all clocks applied to the processor?
2) Please check and confirm that all of them are stable when RCW is read from the I2C EEPROM.
3) Please provide the RCW binary image for inspection.