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/24...
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?
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 / 512100 MHz / 512 = 195.3125 kHz
After RCW loading and PLL lock:
HRESET_Bshould 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_BHRESET_BRESET_REQ_BASLEEPCLK_OUT, if configured
Once debug access is established by using RCW override/safe-RCW or by isolating RESET_REQ_B, inspect:
RSTCRRSTRQSRRSTRQPBLSRRSTRQMR
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