LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW Hello, This follows up the earlier thread (June is out of office): https://community.nxp.com/t5/QorIQ/LS1046A-custom-board-cold-boot-fails-from-eMMC-SD-and-QSPI/m-p/2416533 Summary Native cold boot from SD stalls with HRESET_B LOW. Debugger-assisted boot (CodeWarrior rcw.apply()) reaches U-Boot with the same RCW, PBI and card. During the native stall, the PBL starts SD_CLK at about 195 kHz and sends command frames. DAT0 never toggles. The clock then stops, restarts briefly at about 24 kHz, and the bus goes idle. We would like help interpreting this against RM Table 4-8 "RCW State Timing". Setup (board 2, no reset rework) LS1046AXE8T1A Rev 1.0 (SVR 0x87070010). No CPLD; an STM32 BMC does power sequencing and reset. cfg_rcw_src=0x40 (SW8 = 0010 0000, SW5 pole 1 OFF). Primary reference: 100 MHz differential. Clock-select strap IFC_WE_B (cfg_eng_use0). DDR reference: differential. SD card: The same card boots an LS1046ARDB to U-Boot. EVDD = 3.3 V. The SD/eMMC mux is set to the SD slot. RCW EVDD_VSEL = 0b10. RCW: PLL ratios copied from the hard-coded 0x9F example (platform 400 MHz, CPU 1300 MHz, PLL2 1000 MHz / FMan 500 MHz, DDR 1600 MT/s), both SerDes disabled: 0810000d 0a000000 00000000 00000000 00000000 00f00012 60040000 c1000000 00000000 00000000 00000000 0001c83e 00004504 24001102 00000096 00000001 PBI: identical to the stream in the earlier thread, ending with 08610040 6d8bdebf (END/CRC). Reset circuit: PORESET_B is driven by an open-drain MOSFET with a 10 kΩ pull-up to 1.8 V. TRST_B is controlled separately and released 1 ms after PORESET_B. HRESET_B has a 4.7 kΩ pull-up. Native cold-boot observations (no debugger connected) Times are approximate. t = 0 is the ASLEEP falling edge, which coincided with PORESET_B rising in a separate capture. ≈ +0.5 ms: SD_CLK starts at 192–200 kHz (about 100 MHz/512 by our arithmetic). CMD is idle. ≈ +3.2 ms: CMD frames begin. The frame shape looks like CMD0 (40 00 00 00 00 95), but we have not decoded it. ≈ +9.6 ms: SD_CLK stops for about 1 ms. ≈ +10.6 ms: a few transitions appear on CMD and DAT0 with no clock. ≈ +10.7 to +11.2 ms: SD_CLK runs at 24.39 kHz (about 100 MHz/4096) for about 16 cycles, with no CMD frame. ≈ +11.0 ms: ASLEEP goes HIGH. Afterwards: no CLK, CMD or DAT0 activity for the rest of the 250 ms window. HRESET_B stays LOW. HRESET_B is LOW before PORESET_B is released and stays LOW afterwards. RESET_REQ_B stays HIGH with the card inserted. Without a card, RESET_REQ_B goes LOW. CCS access during the stall ccs::config_chain {ls1043a dap sap2} is accepted. ccs::display_mem 2 0x01ee0000 4 0 1 returns "Scan timeout". Debugger-assisted boot (works) set_source(0x40) and set_data({13: 0x00004504}) (the same value as on the card), then apply(). RCWSR then matches the card. U-Boot reports CPU 1300, platform 400, DDR 1600, FMan 500 MHz. SD initialisation and FIP loading succeed. Questions Per Table 4-8 "RCW State Timing", what SD_CLK frequencies and transitions should we see with a 100 MHz SYSCLK? Does "~195 kHz → stop → ~24 kHz burst → idle" mean the PBL timed out during card identification, reset the eSDHC, or reached a later state? Which SD command sequence does the PBL issue (CMD0/CMD8/ACMD41 …), with what retries and timeouts? If the card doesn't answer, should RESET_REQ_B assert, and after how long? Is "Scan timeout" on SAP2 expected while HRESET_B is LOW? If so, what JTAG-accessible status can show PBL progress in this state? Could a slow PORESET_B rise ( specification ≤ 1 SYSCLK) cause this behaviour? Hard-coded 0x9F with no card: HRESET_B did not go HIGH after PORESET_B release. How should we interpret this? Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW Hello,
The waveform indicates the device never completed the RCW/PLL transition. It is not yet in the normal PBI/eSDHC operating phase.
1. Expected SD_CLK with 100 MHz SYSCLK
For RCW loading:
SD_CLK = SYSCLK / 512
100 MHz / 512 = 195.3125 kHz
After RCW loading and PLL lock:
HRESET_B should deassert.
The platform clock switches.
SD_CLK = platform clock / 80 .
With a 400 MHz platform clock, this is approximately 5 MHz. NXP describes this transition as the indication that PLL lock and RCW loading completed.
Therefore:
~195 kHz → stop → ~24 kHz burst → idle
does not represent the documented later-state transition. The 24 kHz value is approximately 100 MHz / 4096 ; treat it as a reset/default-divider or restart artifact, not proof that PBL reached PBI loading. The clock alone cannot distinguish an SD identification timeout from an eSDHC reset.
2. SD commands, retries, and RESET_REQ_B
The expected SD-identification flow is broadly:
CMD0
CMD8
CMD55 + ACMD41 repeated until the card is ready
CMD2
CMD3
CMD7
then block reads for RCW/PBI data
CMD1 is normally the eMMC initialization command, not the SD-card equivalent.
The exact LS1043A ROM retry count and per-command timeout are not specified in the accessible NXP support material; they should not be inferred from the waveform. NXP documentation instead describes the terminal behavior: if the selected SD source is unavailable, the SoC does not fall back to another source; it asserts RESET_REQ_B and halts.
Thus, if the card is completely absent, RESET_REQ_B should eventually assert. There is no documented fixed “assert after exactly N ms” value to use as a pass/fail limit. If it remains high while HRESET_B remains low, the device may still be before the terminal PBL error path—or the board may be masking/interfering with RESET_REQ_B .
3. SAP2 “Scan timeout”
Yes, this is expected while HRESET_B is still asserted. The same reset signature— PORESET_B released, HRESET_B low, RESET_REQ_B high, and the processor inaccessible through the debug path—is associated with an early reset/boot condition.
Before SAP2 becomes accessible, there is no dependable CCSR register that reports PBL progress. Use:
PORESET_B
HRESET_B
RESET_REQ_B
ASLEEP
CLK_OUT , if configured
Once debug access is established by using RCW override/safe-RCW or by isolating RESET_REQ_B , inspect:
RSTCR
RSTRQSR
RSTRQPBLSR
RSTRQMR
NXP specifically recommends these reset registers when RESET_REQ_B access is possible.
4. Slow PORESET_B rise
Yes. A slow or poorly shaped PORESET_B release can violate the reset-initialization timing and cause incorrect strap, clock, or PLL sampling. With a 100 MHz SYSCLK, the stated limit of one SYSCLK is approximately 10 ns. Verify the actual voltage crossing and rise time directly at the LS1043A pin, not only at the reset-generator output.
Also verify that RESET_REQ_B is not feeding back into PORESET_B ; NXP recommends an isolation option during bring-up because boot failures can otherwise create a reset loop that prevents JTAG access.
5. Meaning of the 0x9F test
0x9F is the hard-coded-RCW/debug discriminator. With a valid clock and reset sequence, it should remove dependence on reading the RCW from the SD card. Therefore, if HRESET_B still never rises with no card installed, the fault is probably earlier than SD-card identification:
SYSCLK/differential clock selection or quality
PLL lock
RCW strap decode
reset electrical timing
reset feedback or JTAG/TRST state
In other words, the 0x9F result argues against “missing card” as the primary cause. First prove that HRESET_B rises with 0x9F and a clean reset/clock setup; then return to SD RCW loading.
Regards Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW Hello, We are looking into what you said - prove that HRESET_B rises with 0x9F, as of now we are observing same behaviour as SD card in which HRESET_B being low and ASLEEP going low first and then high back. Also We tried with SD, EMMC as well as QSPI and is observing same cold boot stall and same HRESET_B & ASLEEP behaviour. Below is the CCS console we got when connected during stall - can anything be done to find at what the custom board is failing. CCS console logCCS console logCCS console log Thank you Re: LS1046A custom board: PBL SD_CLK drops 195 kHz to 24 kHz, then idle; HRESET_B stuck LOW Hi,
The CCS capture does not prove that HRESET_B rises with 0x9F. It proves that JTAG detects the TAP/IDCODE, but subsequent accesses to the LS1046A system space fail with Scan timeout . The same symptom is documented for this cold-boot case.
Interpretation
0x9F is an isolation test for hard-coded RCW using the differential SYSCLK path; it is not a guarantee of successful boot.
During a valid sequence, HRESET_B is asserted during POR and should release after RCW/PLL completion; ASLEEP should transition after PBI execution.
A brief HRESET_B high followed by low indicates that the processor may have passed the RCW/PLL stage but then entered another reset/stall condition. The oscilloscope must show whether PORESET_B or RESET_REQ_B also reasserts.
Recommended isolation test
Set the board to 0x9F.
Disconnect the CodeWarrior TAP completely.
Perform a clean power cycle.
Capture these signals together:
PORESET_B
HRESET_B
RESET_REQ_B
TRST_B
ASLEEP
DIFF_SYSCLK
relevant power-good rails
Interpretation:
PORESET_B falls again: investigate the external supervisor/BMC/power-good logic.
PORESET_B remains high but HRESET_B stays low: investigate differential clock selection, PLL/RCW settings, HRESET_B pull-up/drive, and TRST_B/COP reset wiring.
HRESET_B rises, ASLEEP falls, then both restart: investigate RESET_REQ_B feedback and the PBI/boot-source transaction.
Also verify that HRESET_B and PORESET_B are not driven by the same source. HRESET_B should have its own pull-up and RESET_REQ_B should be isolated from PORESET_B/HRESET_B during bring-up.
CCS actions
After the waveform capture, reconnect CCS and use the LS1043A/LS1046A chain position, not DAP or SAP2, to read:
0x01EE00B4 Reset Request Preboot Loader Status
0x01EE00C8 Reset Request Status
These registers are specifically recommended for this failure mode.
If those reads also return Scan timeout , CCS cannot reach the CCSR bus while the device is stalled; the waveform and reset schematic are then the primary evidence. Enable CCS protocol logging at DEBUG level and capture the complete low-level log.
Bottom line: because SD, eMMC, and QSPI show the same behavior, the common failure is probably before or independent of the storage device—reset sequencing, clock/PLL selection, TRST_B/HRESET_B wiring, or RESET_REQ_B feedback.
regards
查看全文
