AM2434: AM2434 Bring-up - not coming out of Reset

Hi Andrew,

Based on the information you are providing, I don't see any obvious red flags.  You highlighted the critical things I would normally ask for:

• Power Supply Sequencing
• PORz release timing
• Clock stability
• Boot mode selection
• JTAG

When you say you are not seeing any life on the JTAG port, what are you trying to do, and what is the error/messaging you get?  Please make sure to include both what is shown in any pop up boxes as well as what is in the console.  If you haven't already, can you try doing a Test Connection from the Target Configuration?  Please post what messaging you get back from that as well.

What image are you putting on the QSPI?  Can you try an SBL Null example or similar?

Finally, I was able to go pull up the schematic from the review back in January, and I see a couple of things I wanted to flag that may have been missed on the schematic review:

1. The JTAG lines are missing their pull resistors:  TCK, TDI, and TMS need to be pulled high to the correct voltage, VDDSHV_MCU.  Using a 4.7kohm resistor here should be fine
2. The Reset inputs into the MCU are all directly driven (by an AND gate for MCU_PORz and a Schmitt Trigger for RESET_REQz and MCU_RESETz) without any pulldowns.  Can you add a pulldown resistor to the lines just before the input into the AM2434 to keep the MCU in reset until everything is ready to to released from reset?

Thanks,
Mike

Thanks for your response, Mike.

The chip seems to stay in reset state when MCU_PORn is released: The reset output POR_OUTn remains active (LOW). 

The SYSCLKOUT0 on Pin B14 is also inactive despite a valid clock on MCU_OSC0_XI The design review asked me to put this out to a test point for debugging purposes. The data sheet seems to suggest the default configuration of this pin is GPIO1_62, so it may not be useful until I can get the device booted: Would you expect to see a clock here when coming out of Reset?

(I am happy to share the final schematics with the points raised in the review addressed, but that would have to away from the public forum)

My suspicion is there is something that is holding the chip in RESET state - which would mean the JTAG is unavailable.

I have tried both NO_BOOT and QSPI_BOOT modes - albeit with an un-programmed QSPI Flash, since that would be done via JTAG.

I had used Test Configuration from the Target Config screen to try a JTAG scan. This invokes the dbgjtag tool with the integrity option:

[Start]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\redacted\AppData\Local\TEXASI~1\
    CCS\ccs1240\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 560/2xx-class product.
This utility will load the program 'xds2xxu.out'.
The library build date was 'Jun  2 2023'.
The library build time was '17:37:16'.
The library package version is '9.12.0.00150'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '13' (0x0000000d).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller.
This utility has successfully reset the controller.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[An error has occurred and this utility has aborted]--------------------

This error is generated by TI's USCIF driver or utilities.

The value is '-233' (0xffffff17).
The title is 'SC_ERR_PATH_BROKEN'.

The explanation is:
The JTAG IR and DR scan-paths cannot circulate bits, they may be broken.
An attempt to scan the JTAG scan-path has failed.
The target's JTAG scan-path appears to be broken
with a stuck-at-ones or stuck-at-zero fault.

[End]

The point about the pull ups on TCK TMS TDI is easy to try - these were omitted as I followed SPRU655i Table 15 / Figure 10, although I now realise Table 6-86 in the AM2434 data sheet says:  The internal pull-up can be used to hold a valid logic high level if no PCB signal trace is connected to the ball. So an external pull up is required.

I fear that without the chip coming out of RESET this won't make much difference, so I will try the pull downs on the Reset Inputs first.

Thanks again - will report back findings later today.

OK -

I added 4K7 pull down to the MCU_PORn input - this had no effect

I added 4K7 pull-up to the suggested JTAG pins - this made no difference in the symptoms.

Andrew,

Thanks for testing the pull resistors on MCU_PORn and the JTAG lines.  Something else that we just noticed was on the TPS386000, the VDD line is 5V, but the nMR line is only pulled to 3.3V.  Per the TPS386000 datasheet, the minimum V_IH for nMR is 0.7*VDD, which is 3.5V.  There is some chance the TPS386000 is never reading nMR as logic high.  Can you try replacing R121 with a pullup to 5V instead of 3.3V?

Thanks,
Mike

Interesting - I can try this, but the combined output of the RESETn signals from the TPS386000 do behave sensibly, and the Master RESET Switch works fine, even out of spec with the pull-up to 3V3.  I have a nice oscillogram showing the rails coming up in the correct order and then the combined RESETn releasing:

• Green is the +5V
• Yellow is +3V3
• Blue is +1V8
• Pink is +0V85

MCU_PORn releases a little under 20ms after the rails are OK. This is more than the minimum required 9.5ms so should be fine. This was probed at the output of the AND gate that combines it with EMU_RSTn, so it should be what the AM2434 is seeing.

RESET_STATUSn output remains LOW and never changes (also no change on POR_OUTn)

I will repeat the test tomorrow morning with MRn pulled up to +5V

Hi Andrew,

Thanks for the waveform, that is really helpful.

A couple of additional items just to double check:

Are you meeting the slew rate requirements on the power rails going into the AM2434?  Section 7.10.2.1 of the AM243x Datasheet contains the slew rate information.

I assume you are probing the MCU_PORz, RESETSTATUSz, and POR_OUT lines directly coming out of the AM2434 package, and not on the other side of any devices, correct?

Can you confirm the clock source is up and stable at least 1.2ms before MCU_PORz is released?  Any chance you could get it added to the waveforms showing the power supplies and MCU_PORz release?

Thanks,
Mike

Power supply slew rates

Ref AM2434 Data Sheet 7.10.2.1 max slew rate is 18mV/us

3.3V Comes up first - linear ramp from 0V to 3.3V in 421uS = 7.8mV/us << 18mV/us
0.5ms delay
1.8V Comes up next - linear ramp from 0V to about 1.5V in 138us then more slowly to 1.8V. Fastest part of ramp is 10.8mV/us <<18mV/us
Clock is within spec within 150us of 1.8V supply coming online.
2ms delay from 1.8V supply coming up.
0.85V Comes up last - linear ramp from 0V to 0.82V in 224uS equating to 3.67mV/us << 18mV/us

Mike Pridgen said:

I assume you are probing the MCU_PORz, RESETSTATUSz, and POR_OUT lines directly coming out of the AM2434 package, and not on the other side of any devices, correct?

Yes - I have sent you current schematics via Jorgen - I am using TP510 TP511 TP512 and TP513 on sheet 5 to measure the resets. 

Hi Andrew,

Thanks for sharing the schematics, Jorgen did pass them on to me.

Honestly, I'm a little bit stumped on this one.  I'm working with the team some to see if anyone else has any ideas, but so far, no one is really coming up with anything that we haven't already thought of.

One other thing that is a potential thing to check would be the clock coming up that long before the 0.85V rail.  There is some chance this is could cause some weird latchup state in the device.  However, we checked the TMDS243EVM, and the clock source there starts about 1ms before 0.85V fully ramps up.  Is there any way you could have enable on the clock buffer not go true until the 0.85V rail ramps up?  I'm not sure when the PGOOD on the PMIC goes true relative to the 0.85V rail, but it may be a potential source for this.

The other question we had was on how many boards were failing.  Jorgen mentioned you were trying to get a second board alive, but it was still in progress.  Once you get the second board up, we would be interested to know if it has the same problems.

Final question:  what is the full part number of the device you are using?  I'm looking specifically for the silicon revision, but having the whole part number would be useful.

Thanks for your patience working through this one with me.

Thanks,
Mike