T1042 HRESET_B Negation Problem in Power On Reset Sequence

[oguzhanemre_ard]

Hi,

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?

Edit:

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.

Regards,

Oguzhan

[ufedor]

Which traces show data read from the NOR Flash so it will be possible to check that RCW is correctly applied during POR?

Please provide the processor connection schematics for inspection as searchable PDF.

[yusufalti333]

Hello ufedor‌

Could physically double-sized nor flash( compared to RDB, it has 128 MB ) connected  to IFC interface cause this problem ? There is 256 MB nor flash in this design, instead of 128 MB.

If so, what should be done ? Thanks.

[ufedor]

Use digital scope to check how RCW is read from the NOR Flash.

[oguzhanemre_ard]

Unfortunately, there is no activity in both IFC_A and IFC_AD after FPGA drives them as configuration inputs. When CodeWarrior TAP is used for Dump Flash action situation changes.

Btw, CPU DIFF_SYSCLK, Serdes REF_CLK1 and REF_CLK2 is not given yet (oscillator not programmed) could they also cause a problem? However SYSCLK and DDRCLK is already given.

[ufedor]

What is the POR level of the IFC_WE0_B/cfg_eng_use0?

You wrote:

> there is no activity in both IFC_A and IFC_AD after FPGA drives them as configuration inputs

Please provide traces simultaneously showing:

a) low->high edge of PORESET_B

b) {IFC_AD[8:15], IFC_CLE}

c) 6-8 SYSCLK cycles after the low->high edge of PORESET_B