I am trying to bring up a custom T1042 CPU. During power-on reset sequence via driving hard-coded cfg_rcw_src pins (driven by the FPGA), a proper HRESET timing has been observed as shown in RM Figure 4-1. So I have burnt my custom RCW (to address 0xE800_0000) and uboot (to 0xEFF4_0000) to the NOR Flash by using CodeWarrior TAP(write operation is verified by CodeWarrior and data is manually checked by checking hexdump from Flash locations).
However, when the cfg_rcw_src option that addresses NOR Flash is driven on IFC interface, CPU asserts HRESET_B but does not negates. Also RST_REQ_B and CPU_ASLEEP does not follow the reference timing. When CPU's internal registers are checked via CodeWarrior TAP in debug mode the expected cfg_rcw_src (0x27 for NOR Flash) and other conf inputs (eng_use_0/1/2, ifc_te, dram_type) are seen as they got sampled correct. Also, while in debug mode, by clicking resume and suspend right after it makes us see output at the serial for uboot. What could be the reason that avoids the sequence to be done?
Please see the values of the used configuration inputs' POR values and attached scope capturings of the them with respect to PORESET_B deassertion:
- cfg_rcw_src[0:8] = 0_0010_0111 - (rcw_srcn_10cyc_wrt_poreset.png)
- eng_use_0/1/2 = 1 - 100 MHz single ended clk is given (eng_use_1us_wrt_poreset.png)
- ifc_te = 0,
- dram_type = 0
Previously, I said there was no activity on IFC_A & IFC_AD buses after PORESET_B is deasserted and IFC pins are released to high-Z by FPGA. However, I realized there are some (and last) attempts on cfg_rcw_src pins. In similar amounts of time after low-to-high transition of PORESET_B, there happens some assertions. Please see attached srcn_activity.png and IFC_OE_B_activity.png files.