my system only starts after a second reset

[sandrobastos]

hi,

i have a code that boot on twr-vf65gs10, from qspi and running in ddr, i mean, it's stored on qspi non xip mode, then, after reset or power on, vybrid copies the code to ddr and run it - ok, it works fine.

the problem: with our own hardware, that is strongly similar to twr, it only runs after a second reset; after power on the system does not start, then i press the reset button and it runs.

our hardware manages to boot from qspi since the destination memory is intram, or xip mode; in those cases, the system runs on power on; but if the destination memory is ddr, we need a second reset...

the ddr p/n is identical and so is the circuit.

has anyone had a similar issue?

thank you,

BrunoCastelucci‌

DavidSeymour‌

karinavalencia‌

TheAdmiral‌

[sandrobastos · Accepted solution]

Hi James,

it's finally working, thanks to this post:

https://community.nxp.com/thread/308902#comment-340511 

i put my original 'quadspi_boot.c', based on IAR 'vf65gs10_a5_ddr.mac' back to my project and only changed:

DDRMC_CR154 to 0x682C0000      (* byte_swap32(0x400ae268), byte_swap32(0x682c0000), *)

before was: 0x68200000

how can i run DDR_StressTest on my board?

thank you for your time,

thanks to Ioseph

best regards,

jamesbone‌

ioseph_martinez

‌

[jackblather]

I have seen this numerous times, too. And not just with Vybrid, but also with the iMXx series.

I also would like to know more about this.

[jamesbone]

Hello Sandro,

Is your FAE helping you with this thread?

[sandrobastos]

Hello James,

Nobody answered to it so far...

Thank you

[jamesbone]

Hello Sandro,

In order to understand what it is happening do you think you can share an screenshot of the power supply and reset to review if the  Startup condition, of the power sequence it is correct.  Usually I have seen this kind of problems of the Power Supply in the power up sequence, once the device it is Up you only need to apply Reset and seems that you need a double reset to made the board working.   Are you using any  PMIC? which one?

Have a great day,

Jaime

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[sandrobastos]

hi jamesbone,

follow the screenshots of 3.3V, 1.2V (ddr) and reset, signals; also follow the PMIC circuit.

note that, the reset time is approximately 280ms.

Keep in mind that my 1V2 ballast transistor is fed by 1.5V (not by 3.3V)

robsontenedini‌

[jamesbone]

Hello Sandro,

Could you please attach a copy of the schematic and a copy of he DDR initialization code being used?

If using the NXP source, the file has a name something like: Vybrid.c

Even if you made no changes to this file, I want to check vs recent changes that may or may not have been made to it.

If you are using a code that has already been compiled, could you please provide the u-boot date from the string at the top of the debug print out.

[sandrobastos]

hi James,

the following files were attached:

- "ddr_sheet.pdf" -> ddr schematics

- "boot_ddr.icf"  -> IAR linker file

- "quadspi_boot.c" and "quadspi_boot.h"  -> contains IVT, DCD, boot data and QSPI tables used by vybrid in boot proccess.

thank you for helping,

sandro

[jamesbone]

There are some easy steps to help narrow down the problem:

1.  Place a scope probe on the QSPI_CLK trace or one of the data traces and see if the QSPI is active at all.

2. If there does appear to be activity on the QSPI interface,  place a probe on the DDR_CKE0 trace/resistor and see if the CKE0 signal is going high. This would indicate that the processor got valid information from the QSPI memory, correctly initialized the processor DDR interface and is beginning to initialize the DDR memory. That must be done before the boot sequence can then transfer the remainder of the u-boot file into DDR memory for further processing.

[sandrobastos]

hi James,

you can see in the attached pictures that, 8ms after reset rises (dark blue), you see some activity on qspi clk (purple), i believe at this moment, vybrid is reading the SFLASH_CONFIGURATION_PARAM in order to correctly set up the qspi...

the qspi clock is 60MHz

after about ~16ms from this activity, you can see the ddr cke (light blue) goes high and the qspi clk comes back to activity, in order to read the code from qspi and write it to ddr.

actually, if i connect the i-jet to the frozen board, using the 'attach to running target' feature, i can see the code correctly written in the ddr (0x80000000), but it does not start...

the second picture was caught pressing the reset button; it's identical to the first one (power on reset), but in this case, the system starts correctly...

thank you,

[jamesbone]

Hello Sandro,

Base on the information and screenshots that you provide, our Applications team came into the following findings:

1. Why is there so much noise on the RESET_B trace? +/- 200 mV. That's almost 25% ripple, if it is coming from the power supply.  Check up on that.

2. The pull up resistor on the DDR_RESET trace (R50). Depopulate this. It is violating the requirements of the JEDEC standards for power up sequencing. At first glance, this might be the biggest contributing problem.

3. From the DCD file, the IOMUX settings for pins DDR_CS_D_15 through DDR_CS_D_0 are wrong. (0x4004827C - 0x400482B8). Bit 16 is DDR_INPUT. It controls whether the input of the pad uses a CMOS gate or a differential gate (with VREF as the reference point). For best operations, DDR_INPUT for the data pads should be selected to 1 = Differential input mode. Setting the clock trace to Differential input mode does nothing, since the clock is never an input. So leaving the clock trace as DDR_INPUT = 1 is okay.

4. There are numberous registers that are set incorrectly in the DCD file. I am attaching the current DCD file used by our BSP team as a reference (vybrid_10.c). I am also attaching a register programming aid for Vybrid for DDR3. The register programming aid is a handy reference.

Attachments

• Vybrid_DDRMC_DDR3_register_programming_aid_1V1.xlsx186.1 KB Preview
• vybrid_10.c.zip4.8 KB

[sandrobastos]

hi James,

Some points regarding to DCD for boot via QSPI -> DDR:

1- the dcd i sent you is from "vf65gs10_a5_ddr.mac" (IAR macro for DDR) and it works fine at TWR (with the same DDR we use);

2- the file you sent me ('vybrid_10.c') is not a DCD (device configuration data); i mean, it's not a table but a function
that should be called anywhere;

3- i took all register and values from your "Vybrid_DDRMC_DDR3_register_programming_aid_1V1.xlsx", from the tab "RealView.inc file",
and translate it to the DCD format, for example:

Excel:
"setmem /32    0x40048220 =    0x00000180    // IOMUXC_DDR_A_15    "

My file.c:
"byte_swap32(0x40048220), byte_swap32(0x00000180),"

and so on...

3- after some commands there is a code to check if the previous command was done;

ex.:

    DCD_WRITE_CMD4(1,0,0),
    byte_swap32(0x40050030), byte_swap32(0x2001), // pll2
    
    // check something...    
    //while ((reg32_read(0x40050030) & 0x80000000) != 0x80000000) {}
    DCD_CHECK_DATA_CMD4(0,1),
    byte_swap32(0x40050030), byte_swap32(0x80000000),

- should i keep these lines in my dcd?

4- the DCD i made from RealView.inc didn't work too, even after the second reset;

5- please check attached dcd file.

thank you,

jamesbone‌

[sandrobastos]

hi James,

- i couldn't open the attached files: "not authorized..."

- regarding to the signal noise, it's due to a bad grounding of my scope leads;

- the R50 is actually not populated, but the R52 (DDR_CKE) is a pull up (i'll try to pull it down to test);

jamesbone‌

thank you very much,

regards

[jamesbone]

Hello Sandro,

Here are the files , lets try again:

[sandrobastos]

dear James,

could you please attach the header files for "vybrid_10.c"?

there are many definitions i can't guess what is it.

ex.: "IOMUXC_DDR_A15", "DDR_PHY000", "DDR_CR000"...

    __raw_writel(DDR_IOMUX, IOMUXC_DDR_A15);
    __raw_writel(PHY_DQ_TIMING, DDR_PHY000);

    __raw_writel(0x00000600, DDR_CR000);    /* LPDDR2 or DDR3 */

thank you,

[jackblather]

This happens on the iMX6 even if the power never is turned off. Just rebooting it (soft boot) often results in this hung situation. It hangs after reporting about the device tree blob:

Kernel image @ 0x10800000 [ 0x000000 - 0x585f58 ]
## Flattened Device Tree blob at 13000000
   Booting using the fdt blob at 0x13000000
   reserving fdt memory region: addr=13000000 size=c000
   Using Device Tree in place at 13000000, end 1300efff

It hangs right after this. A hard reset allows it to boot.