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

[yusufalti333]

Hello ufedor‌,

This problem is solved. The reason is, board signals are not working properly during power on sequence IF Code Warrior tab is connected to our custom board. We were also writing to 0xE800_0000 until last week. 

Writing RCW to 0xE000_0000 and removing CW TAB before POR did fix the problem. 

[ufedor]

U-Boot relocation is performed by relative addressing (not absolute).

[yusufalti333]

Hello ufedor,

I do not see the name of my custom boards nor flash device on this list. I was using default configuration of Code Warrior while doing flash programming. I will write my RCW on 0xE000_0000 but I just realized this. Can this situation cause a problem ? Or just aligning base from 0xE8000_0000 to 0xE000_0000 on 'Base Address' column is simple enough ? 

Thanks, Regards.

[ufedor]

The NOR Flash IFC chip-select has to be modified for base address 0xE0000000.

RCW also has to be programmed to 0xE0000000.

In the Flash Programmer it is possible to select 128MB NOR Flash.

[yusufalti333]

Hello ufedor,

The default flash device is "JS28F00AM29EWL" when I import T1042D4RDB NOR Flash Programming options.

In our design we used "S70GL02GS"  (https://www.cypress.com/documentation/datasheets/s70gl02gs-2gbit-256mbytes-30v-flash-memory ) refer here.

Which flash device option is recommended for "S70GL02GS". I couln't find it on the Devices list opened with "Add Device" Button.

S29GL01GP seems the closest configuration for our device but It does not have "128Mx16x2" option.

[ufedor]

> "128Mx16x2"

This means 32-bit-wide data bus, but IFC has only 16 AD lines.

You wrote:

> I have burnt my custom RCW (to address 0xE800_0000) and uboot (to 0xEFF4_0000)

> to the NOR Flash by using CodeWarrior

Which NOR Flash was selected?

[yusufalti333]

Hello, 

>This means 32-bit-wide data bus, but IFC has only 16 AD lines.

I thought that means 128 Megaybte, 16 bit width with 2 nor flash (total: 256 Megabyte) chip configuration. So in this case, 16x1 means 16 bit width data bus, then what is the meaning of 64M or 128M ?

>You wrote:

>> I have burnt my custom RCW (to address 0xE800_0000) and uboot (to 0xEFF4_0000)

>> to the NOR Flash by using CodeWarrior

>Which NOR Flash was selected?

It was default (JS28F00AM29EWL 64x16x1) and it was working with succeded feedback logs on code warrior console. I also checked with Flash Dump actions, RCW and U-boot was writing without any error and written data was correct (0xE000_0000 and 0xE800_0000 has RCW data, 0xEFF4_0000 has U-boot data). I am also able to write 0xE000_0000 by selecting "JS28F00AM29EWL 64x16x1"  and writing "0xE000_0000" to Base Address column.

I just wanted to be sure that using different device name configuration ("JS28F00AM29EWL") with my own device ("S70GL02GS") can be the reason of this rcw reading problem ?

EDIT:  The device configuration named "SL29GL01GP 64x16x1" is also working (tried with dump flash, program/verify and  erase commands).

I also get confused about that, Flash Dump action is working well with all the addresses that I want to check. Code Warrior TAB is writing/reading from NOR flash correctly. Can we still say that we can not read RCW from NOR Flash during POWER ON RESET SEQUENCE ?

Thanks.

[ufedor]

> It was default (JS28F00AM29EWL 64x16x1)

Use this selection and program RCW to 0xE0000000.

[ufedor]

Yes, this is a problem.

For the 256MB Flash the RCW programming address has to be 0xE0000000 because in the Power Architecture each window must be aligned to its size.

In the specific case the RCW was written to the middle of the NOR Flash device, but during boot physical offset 0 is used to read RCW.

[yusufalti333]

Thanks for the reply, 

In this case, I assume a new .tcl file is needed to apply law entry between 0xE000_0000 and 0xEFFF_FFFF,
Does U-boot also need a relocation (writing to 0xE7F4_000 instead of 0xEFF4_0000)?
Regards.

[ufedor]

The requested traces must simultaneously show:

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

[oguzhanemre_ard]

Sorry but due to incapableness of touching those pads in the same time, I did separate the scope shots each other yet sampling every one of them with respect to PORESET_B's low->high edge. 

- sysclk.png shows used 100MHz clock input to have a reference for IFC_AD[8:15] (IFC_CLE is unfortunately untouchable due design)

- IFC_AD[8:15] = rcw_srcn_10cyc_wrt_poreset.png shots have 20ns/div sample rate so roughly represents 2 sysclk cycles. So I've taken scope shots for 10 cycles long before and after PORESET_B low to high based trigger setting.

 If it is still not sufficient, please paraphrase the requirements to avoid our misunderstanding.

[ufedor]

Where is rcw_src8?

The RESET_REQ_B is asserted after ~500us after PORESET_B is deasserted which could correspond to a PLL inability to lock.

Which exactly RCW binary image is used?

Which clocks (frequencies) are applied to the processor?

[oguzhanemre_ard]

- rcw_src8 is untouchable because of board design.

- RCW binary file is attached.

- SYSCLK = 100 MHz, DDRCLK = 100 MHz, DIFF_SYSCLK/_B is not given. Although we don't use DIFF_SYSCLK, this pair is not pulled low. Could it be a reason to PLL lock issue?

[ufedor]

What is the SerDes reference clock(s) frequency?

[oguzhanemre_ard]

Until now SerDes reference clocks were not given (SD1_REF_CLKx_P/N pins were left floating since the oscillator is not programmed).

Also the clock signals;

- DIFF_SYSCLK/_B,

- SD1_REF_CLKx_P/N,

were not pulled down but floating.

So now, as denoted in Design Checklist - AN4825 these pins are connected to GND. And also I made some changes in RCW like both PLLs are programmed to be powered down. (not sure if at least one of the PLLs has to be used for PoR sequence)

[ufedor]

> both PLLs are programmed to be powered down

Do you see RESET_REQ_B still asserted with this RCW?

[oguzhanemre_ard]

Yes, unfortunately.

[ufedor]

Please use the scope to ensure that RCW is correctly read from the NOR Flash.

Also ensure that all signals having note 5 in the QorIQ T1042, T1022 Data Sheet, Table 1. Pinout list by bus are not pulled low during POR.

[oguzhanemre_ard]

The note 5 of from Table 1 in datasheet is already satisfied. And please see the attached scope shots (srcn_activity.png files) of the question which shows the attempt of (cfg_rcw_src[0:4]) IFC interface to read RCW. After ~445 us (under 100 MHz SYSCLK) from PORESET_B's negation there seen two consecutive activity on these buses.

Can we still have a suspicion on PLL lock issue at this point? Would IFC interface start to assert its pins without verifying PLLs are locked?

Does CPU require at least one of the SerDes REF clocks (SD1_REF_CLKn_P/N) to be given properly?