AM67A: AM67A Custom Hardware - Stuck In Warm Reset Loop

Hello Bill,

Please allow us some time to  look into the summary of your AM67A custom board behavior and internally discuss the details.

We'll try to get back to you with a response by the end of this week.

We appreciate your patience !

Thanks

Best Regards

Anastas Yordanov

Hello Bill,

Are you able to share the schematics over private chat for me do a quick check.

Regards,

Sreenivasa

Hi Sreenivasa, 

I am for sure, let me know what the best channel for chat is.

Thanks,

Bill

Hello Bill,

Thank you.

Please share over private chat.

Regards,

Sreenivasa 

Hello Bill,

Thank you.

Received the schematics.

Can you please confirm if the schematics includes DNI marking.

Ex: LPDDR4 ODT pins have pullup and pulldown

The SD card power switch has a 0R that bypasses the switch.

Regards,

Sreenivasa

Hello Bill,

For the SD card , VDD_IO_3V3 seems to have been  used.

This is a fixed 3.3V and will support only legacy speed.

In the software can you confirm you have configure the SD card interface to work only in legacy mode.

In case this is not done, you may have to make the required software changes.

I see a pullup added for the MMC1_CLK

The recommendation is to add a pulldown.

Regards,

Sreenivasa

The TPS6521910 is setup for voltage selection on MMC1 so I will wire it to VDDSHV5 as well as the pullup resistors on the SD card lines.

The pullup on MMC1_CLK has been removed.  I will install a pulldown in it's place per the recommendation.

Confirming that the 0R bypass across the power switch is a DNI.

Confirming also that only pullups are installed on the ODT pins.

I will reprint with the DNI parts X'd out.

Hello Bill, 

Thank you.

Bill Hodgins said:

The TPS6521910 is setup for voltage selection on MMC1 so I will wire it to VDDSHV5 as well as the pullup resistors on the SD card lines.

The pullup on MMC1_CLK has been removed.  I will install a pulldown in it's place per the recommendation.

Ok, let me know how the tests progress.

Can you confirm the PMIC output voltages are expected.

I ask the question since the PMIC feedback is taken after the inductor in the schematics vs taking feedback after the bulk caps.

Regards,

Sreenivasa

Hi Sreenivasa,

I have replaced the SD card pullups with 47kohm to match the checklist recommendations.  I have inserted a 47kohm pulldown on MMC1_CLK.

The PMIC output voltages are as expected.  The sequencing is also as expected per the TPS6521910 TRM.  Sequencing of VCORE (Slot_2) is also behaving as expected per TPS6521910s GPIO activation.  The TPS6521910 holds nRSTOUT for 10ms, as indicated for Slot_3.

Here is what I am measuring with an Agilent 34401A bench meter.

BOOTMODE at PORz Via Scope

DMM Measurements of the BOOTMODE locations are all as expected.

To be sure I measured each BOOTMODE pin in turn with a scope to capture the BOOTMODE state on PORz and monitored for many ms after.

For example, here is BOOTMODE0. All BOOTMODE pins are stable before and after PORz_OUT

All pins report as expected, per the BOOTMODE pin straps.

Hello Bill, 

Thank you.

Checking if you have been able to rewire the IO supply to the pullups and VDDSHV5 IO supply rail.

The IO supply is expected to start at 3.3V and switch to 1.8V to support UHS-I SD card 

Regards,

Sreenivasa

UART BOOTMODE Test

I reconfigured BOOTMODE jumpers to UART mode to see if the expected character “C” is send out out UART0_TXD

Monitored UART0_TXD for 'C’ data activity using an oscilloscope, but see no TXD activity at all.

MCU_RESETSTATz and RESETSTATz continue to pulse low at 32ms.

Hi Sreenivasa,

I will strap in the IO supply next.  UART boot mode findings may reveal that it is not even getting to the ROM boot phase.

Hello Bill,

Thank you for the inputs regarding the UART boot.

I assume the PORz_OUT does not toggle.

Bill Hodgins said:

MCU_RESETSTATz and RESETSTATz continue to pulse low at 32ms.

This is indication of a warm reset happening through software. is the toggling consistent if measured over some time?

I will check internally based on your confirmation of PORz_OUT behavior.

Regards,

Sreenivasa

Hi Sreenivasa,

Confirming that PORz_OUT does not toggle.  Once the PMIC asserts MCU_PORz, PORz_OUT goes high and remains high.

Confirming that the toggling of MCU_RESETSTATz and RESETSTATz is considtent and persistent.  It does not stop.

'Surgery' to rewire both VDDSHV5 and the SD card pullups over to VDD_MMC1 is underway.

Thanks,

Bill

Hello Jason,

Thank you.

Let me check internally and update.

Regards,

Sreenivasa 

Hi Sreenivasa,

VDDSHV5 and the SD card pullups are now wired to VDD_MMC1 output of the PMIC, and verified.

BOOTMODE restrapped to SD card primary boot.  All voltages, including bootmode voltages have been verified.

No change in SD behaviour.  No CLK or DATA activity.  SDCD confirmed low when uSD card is installed.

Other Observations -

As a quick check I disabled the oscillator connected to MCU_OSC0_XI.  Provides some confirmation that this clock may be sourcing the state machine / ROM code generating the 32ms pattern.

If you have any JTAG recommendations I do have an LP-XDS110 on hand.

Thanks,

Bill

Another Observation -

VDD_CANUART erroneously suppled through 2M0 resistor.  Replaced with 0 ohm resistor per BeagleY-AI.  No difference to circuit operation.

NOTE: J722S supplies VDD_CANUART with VDD_IO_RET_CORE through 0.002 ohm (ie. 2 milliohms)  Likely where our error stemmed from.

Hello Bill,

Quick check

D10/MCU_RESETZ/3V3 34[1B]

Is see the MCU_RESETz input floating.

Can you enable the pullup and the series resistor and do a quick check.

Regards,

Sreenivasa

Hello Bill,

D10/MCU_RESETZ/3V3  is floating

Suggested Changes 
R429 - use 10K and populate
DNI R431
Populate series resistor R400

Regards,

Sreenivasa

Hi Sreenivasa,

Confirming that D10/MCU_RESETZ/3V3 is pulled up to VDD_IO_3V3. 

My first debug step was to remove R410 (isolating MCU_RESETz from JTAG TRSTn) and adding a pullup from D10/MCU_RESETZ/3V3 to VDD_IO_3V3.

MCU_RESETz and RESET_REQz go high as soon as the PMIC turns on VDD_IO_3V3.  These lines remain stable and high even when MCU_RESETSTATz and RESETSTATz pulse low.

Thanks,

Bill

Hi Sreenivasa,

The reason I strapped  D10/MCU_RESETZ/3V3 on the other side of R430 is so that JTAG_TRSTn can be isolated, and pulled low, per the checklist. 

I had started with pulling up using R429, and R430 populated but this forces TRSTn high also.

Here is what the checklist indicated on TRSTn.

"TRSTn (B10) - If unused, Each of these balls must be connected to VSS through a separate external pull resistor to ensure these balls are held to a valid logic low level"

In my initial post I note the high state of MCU_RESETz and RESET_REQz.  I can provide a scope capture of these signals when I am back in the lab if helpful.

Would the JTAG interface provide any useful debugging at this point?  Or is it too early in the boot ROM process?  It seems like it is stuck in an early state of the reset state machine.

Thanks,

Bill

Hello Bill,

Thank you for the inputs. Let me check and update. 

Regards,

Sreenivasa

Hello Bill, 

I am looking at the EMU0..EMU1 inputs.

A 3 pin header seems to be used to select between pullup and pulldown

I see the header is made DNI

For normal operation, we expect the pullups to be connected to EMU0 and EMU1. Can you please confirm you have the pullups in place.

This could likely change the state of the SOC operation.

Regards,

Sreenivasa

Hello Bill, 

This is regarding VPP pin connection.

Can you DNI R418.

This may not a reason for the boot issue, but we do not recommend connecting a permanent supply to VPP.

Regards,

Sreenivasa

Hi Sreenivasa,

For EMU0 and EMU1, J12 and J13 are not installed so that PU/PD ladder is not engaged. 

EMU0 and EMU1 are instead pulled up by 10K via R428 and R427 respectively right beside the tag connect header.

Thanks,

BIll

Early in debug I removed R418 (see my initial post).  I also tried a 10k PD on this pin per the BeagleY-AI schematic.

Hello Bill,

Thank you.

Bill Hodgins said:

Early in debug I removed R418 (see my initial post).  I also tried a 10k PD on this pin per the BeagleY-AI schematic.

Please keep R418 as DNI during the debug.

Regards,

Sreenivasa

Hello Bill, 

I have reached out to our software expert to add some guidelines on using memory boozer to view the DEVSTAT registers.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you very much for looking into this.

Much appreciated,

Bill

Hello Bill, 

Thank you. 

As we wait for the expert to add his comments, i wanted to check if you have some analysis during the PMIC selection or design.

The cap values used at the input of the buck converters and the LDO outputs seems to be higher that the ones on the EVM or SK.

Reference is Am64x and AM62x SKs.

Regards,

Sreenivasa

Hi Sreenivasa,

I took a look into voltage ripple at the ouput of the Buck regulators as well as the LDOs.  I am seeing very low ripple voltage on all rails.

Noteworthy is the design is only drawing ~140mA.  When the design boots up and starts drawing more current I will remeasure.

Bill

Hi Bill,

Please check if you are able to connect to the WKUP R5F core. If yes, you can read the DEVSTAT register (0x43000030) using the CCS Memory Browser window and check if the bootmode value is latched correctly in this register for the selected bootmode.

Regards,

Prashant

Hi Bill, 

Can you please review the below:

E8/MCU_PORZ/PMIC_RST_OUT/1V8

The MCU_PORz is directly connected to the open drain output of the PMIC.

Slow slew affects the reset behavior

1. Can you please measure the slew (should be as less as possible - max < 100ns 

Can you change the 10K pullup to 2.2K and do a check.

The pullup is connected to 1.8V supply.

Can you please pull 10K to 3.3V and check. MCU_PORz is 3.3V tolerant.

Note:

I know you have verified; can you please reconfirm if the EMU0..1 pins are set to High.

Regards,

Sreenivasa

Hello Bill,

The concern is use of higher value capacitor.

Bill Hodgins said:

I took a look into voltage ripple at the ouput of the Buck regulators as well as the LDOs.  I am seeing very low ripple voltage on all rails.

Noteworthy is the design is only drawing ~140mA.  When the design boots up and starts drawing more current I will remeasure.

C308 - connected to 5V supply and placed at the buck input of PMIC.

100uF
GC0528
20%
6.3V

Can you please DNI for testing.

Regards,

Sreenivasa

Hi Sreenivasa,

Thank you for your continued support.

C308 has been removed - warm reset loop persists, no MMC clk activity.

Confirming EMU0 and EMU1 high, also confirmed at PORz, below.

Achieving sub <100ns slew will require much lower values I think.

Here is the fitted 10k @ 1V8

2.2k @ 1V8 gets us around 400ns

10k @ 3V3

Reverting to 2.2k @ 1V8 and monitoring PORz_OUT

General EMUx to PORz timing, confirming EMUx high

Thanks,

Bill

Hello Bill, 

Thank you.

Checking if you have been able to make progress on reading the DEVSTAT register?

Regards,

Sreenivasa

Hello Bill, 

Thank you.

Checking if you have been able to make progress on reading the DEVSTAT register?

Regards,

Sreenivasa

Hi Sreenivasa and Prashant,

I have been unable to post to the forum since monday due to a TI error.  It may have been some characters in my plain text response, which was a log of the CCS console.

In short - CCS via XDS110 confims the JTAG chain via Test Connections button, but the WKUP core will not connect.

Bill

CCS Output Log.pdf
Instead of putting the CCS output into the reply, I've pasted it into this pdf.

Also, I have also had a board reworked to replace an AM67A marked chip (original) with a J722S marked chip.  No difference.  Same warm reset pattern.

Hello Bill,

Thank you for the inputs. Let me check if i have any additional inputs.

Regards,

Sreenivasa

Hello Bill, 

I am trying to look at the supply rail source for VDDR_CORE rail. Can you please measure the VDDR_CORE voltage level near to the SOC?

Regards,

Sreenivasa

Hello Bill, 

I understand from the ROM expert, the ~30ms reset is an indication of internal WDT timer timing overflow and also indicates that the boot is not starting.

Please connect VDD_CORE to VDDR_CORE supply rail and do a check.

Regards,

Sreenivasa

Hi Sreenivasa,

Excellent suggestion.  I will try this as soon as I get to the lab.

Bill

Hello Bill,

thank you for the note and good to hear you have been able to make progress.

Regards,

Sreenivasa

Hello Bill,

In case you are working with any of the TI support or Sales team members, the suggestion is to get the schematic reviewed before you build the next board.

Regards,

Sreenivasa

Hi Sreenivasa,

I reviewed the Altium DRC in further detail and did not see any violations associated to the VDDR_CORE connection.

I believe the DRC was satisfied by the ferrite bead connecting VDDR_CORE and VDD_MMC0 so the VDDR_CORE to VDD_CORE interconnect error didn't present as DRC violation.

However, exporting the EDIF along with the checklist into AI provided some concrete findings.

VDDR_CORE

• U61 pins: 8 balls

• Filter/topology:

  • Z21 ferrite connects VDDR_CORE to NetC469_1

  • NetC469_1 connects to U61 W10 + C469 + Z21

• Flag (naming/segmentation): this rail is split across two net names (VDDR_CORE and NetC469_1) joined by a ferrite. That may be intentional “island” filtering — but it’s worth confirming you didn’t accidentally create a rail fragment that’s missing expected decoupling or measurement labels on one side.

I will definately run the next schematic through the support/sales team.

Thank you again for your support,

Bill