Boot depends on 1.8V power

Hello,
I have designed a carrier board and encountered a very strange behavior of the system:
In normal usage, the system doesn’t boot. Using UART3, I see:




[0000.372] W> No fuse-bypass data
[0001.879] E> WP-1 ACK pending
[0001.882] E> Error: 0
[0001.884] E> Task 71 failed (err: 0x32320006)
[0001.888] E> Top caller module: CPUINIT, error module: CPUINIT, reason: 0x06, aux_info: 0x00
[0001.896] I> MB1(1.5.1.0-t194-41334769-59d8a47d) BIT boot status dump :
0000000000011111111110111111111111111111111001111111011100111111110110110000000000000000000000000000000000000000000000000000000011111011000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[0001.926] I> Reset to recovery mode

But if I disconnect the 1.8V, the system boots correctly.

I’m attaching the log of ‘reset-to-recovery’ and ‘full-boot’.
200119-reset-to-recovery.txt (3.06 KB)

200119-No-1v8 - full-boot.txt (115 KB)

Hi, which 1.8V do you mean? What’s the difference between your board and reference board? If this can not re-pro on dev kit, it looks more like a design issue.

Thanks Trumany,

Can you see from the log-file what is happening in the system, and what might cause it?

The 1.8V is the VDD_1V8 supply rail which in reference board is provided by U504 APW7307AZI-TRG.

My design is based on the reference board - I have removed items which I don’t have in my design, such as USB-C staff, but ensured to keep all pull-up/down to the SOM, as is in the reference design.

I’ve looked over strap pins, and I have nothing in my design connected to UARTs (1,2,4,5) TX/RX, and the UART4_RX is pulled down same as in reference design, and ‘FORCE RECOVERY’ (L10) has no connection.

I also looked in my design on any signal connected to VDD_1v8, and verified that it is the same as in the reference board.

I’m attaching the OrCad DSN file, and also a PDF of the VDD_1v8 - you can see that it’s almost same as the reference board - I had to use MP2325GJ-P instead of APW7307AZI and JSHC0520-2R2M for ‘L508’ (L8).

Thanks again,
Ishay
FREEZE_V1.zip (907 KB)

Can’t open .DSN file, please share pdf version schematic if possible. Are you using same level shift to all involved strapping pins? Highly suspect the strapping pins status are different to reference design. It looks like when you disconnect VDD_1V8, the strapping pins status restore to correct during power on. Also the UART_RTS(1/2/4/5) pins are necessary not to be affected during power on.

Hi Trumany, thanks for your prompt reply.

I’ve sent also the PDF of the schematic.

I assume that reviewing the differences will be very difficult.
Can you check what might cause the SOM to report ‘WP-1 ACK pending’ followed by ‘Task 71 failed (err: 0x32320006)’

Can you please send me the list of strapping pins.
I know of UART (1,2,4,5) TX/RX and FORCE RECOVERY, and some JTAG.
Any other which I might missed?

The strapping pins are listed in OEM DG, “Strapping Pins” chapter. We are checking the log info in parallel. You can check all strapping pins status first.

There is only components location pdf file in package.

Thanks again,

Looked there, and verified that also ‘STANDBY_REQ_N’ is not connected.
(All other - checked earlier.)

Waiting for checking the log.

[b]“[0001.879] E> WP-1 ACK pending”

“Waiting for checking the log.”

“There is only components location pdf file in package.”[/b]

Sorry, didn’t see that schematic was not sent. Attaching.

Ktigs-MAIN_V1 v04 26-sep-19.pdf (744 KB)

I didn’t see connections of UART3 but you said the log info is from UART3. Please note that if level shifter implemented on UART3, 100kΩ to supply on the non-Jetson AGX Xavier side of the device.

Sorry for the long delay.

There were no connections on the board for UART3, so for this debug I used vias to connect UART3 to FTDI board.
The specific FTDI board was 3.3, and I’ve connected only the TX.

Note that the failure happen always - even if the FTDI board was not connected.

WP-1 ACK pending means way point setting in PMIC pending, which indicates the carrier board power rail or other thing affect the PMIC power-up. Highly suspect the 1.8V rail on your board. You can measure a full power-on sequence like that in OEM DG to make sure all related signals are good.

Thanks.

Can you please detail how the 1.8V rail can affect the PMIC on the SOM - as it is not connected to the SOM.

I assume that some signal which informs the PMIC that the 1.8V is valid, is not getting into the SOM - but what is this signal???

Not sure how it works, but since board can power on by cut 1.8V, it might be the cause. A full power-on sequence will be helpful to locate issue.