T1042 HRESET_B Negation Problem in Power On Reset Sequence

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

T1042 HRESET_B Negation Problem in Power On Reset Sequence

13,819 Views
oguzhanemre_ard
Contributor II

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?

hreset_b.png

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

Labels (1)
25 Replies

1,620 Views
ufedor
NXP Employee
NXP Employee

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.

0 Kudos

1,620 Views
yusufalti333
Contributor IV

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.

0 Kudos

1,620 Views
ufedor
NXP Employee
NXP Employee

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

0 Kudos

1,620 Views
oguzhanemre_ard
Contributor II

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.

0 Kudos

1,620 Views
ufedor
NXP Employee
NXP Employee

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

0 Kudos