• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 924 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5K2E04: Reset/initialization sequence of DDR3

Lennart Siekmann
Prodigy 160 points
Part Number: AM5K2E04

Hello,

Investigating the initialization of DDR3 memory connected to a TI AM5K2E04, we observe the following behavior:

In conflict with the initialization procedure of DDR3 as defined in JEDEC Standard No. 79-3C, which says "After RESET# is de-asserted, wait for another 500 us until CKE becomes active", the DDRRESET# (pin D20) as well as the CKE signal (DDRCKE0, pin C20) provided by the AM5K2E04 both perform a rising edge about 5 ms after the rising edge of RESET of the AM5K2E04 (Pin AE29), with DDRCKE0 following DDRRESET# with a delay of only 15 ns.

About 600 ms later (!) we observe the "correct" initialization sequence in accordance with the JEDEC specification. This sequence can be traced back to the call of dram_init in U-Boot.

As the first release of the DDR RESET does not comply with the JEDEC Standard, we are concerned that this might lead to unintended behavior of the attached RAM and thus are seeking for a possibility to prevent the DDR Reset signal as provided by the AM5K2E04 from performing the "faulty" first rising edge. 

Is there any possibility to modify the pin's behavior in this early stage after turning on the system?

In SPRS864D (p. 194) it says that "after the POR# pin is deasserted (driven high), all Z group pins, low group pins, and high group pins are set to their reset state and remain in their reset state until otherwise configured by their respective peripheral"

Does this passage also apply to the DDR Reset pin and if so, can the mapping of the pin to a group be modified, thus getting a low state for DDRRESET#?

 

Thanks, best regards

 Lennart

  • 0
    TI__Guru**** 161600 points
    Hi Lennart,

    Do you observe this on K2E EVM or a custom board? Which Processor SDK Linux version are you using?

    Do you see the same behavior when your board is connected to CCS via JTAG and board initialization is done by GEL files?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 300 points
    Dear Yordan,

    Gerald here; I'm a colleague of Lennart from our department which is in charge of the embedded software.
    To answer your question:

    1. We're using our own board
    2. We do not use the Processor SDK Linux

    To provide some more details:
    Our Keystone2 is connected via EMIF16 to a NOR Flash and the boot process is controlled by an external logic (namely a CPLD which manages the boot sequence). The NOR Flash holds UBoot as a standard boot loader; we use UBoot 2016-05 as a base with slight modifications in the later boot stages. The effect described by Lennart is observed in the very early boot stages.

    The BOOTMODE[15:0] pins (DEVSTAT[16:1])are set to 00011-1000110011, which means:

    DEVSTAT[4:1] = 0011 ==> Use EMIF16 as boot device
    DEVSTAT[7:5] = 011 ==> Sys PLL for 100Mhz input clock
    DEVSTAT[8] = 0 ==> ARM Boot Master
    DEVSTAT[10:9] = 10 ==> Use EMIF16 ChipSelect4 (CE2)
    DEVSTAT[11] = -
    DEVSTAT[12] = 1 ==> Use 16-bit accesses on EMIf16
    DEVSTAT[13] = 1 ==> Extended Wait Enabled
    DEVSTAT[15:14] = 00 ==> Use 0x0 as base address
    DEVSTAT[16] = 0 ==> Use EMIF16 as boot device

    The boot sequence created by our CPLD looks like this:
    t_0 = 0 s: \POR pin is released (low -> high)
    t_1 = 100 µs: \RESETFULL pin is released (low -> high); Boot mode pins -> high Z
    t_2 = 200 µs: \RESET pin is released (low -> high)

    Cheers,
    Gerald
  • 0 in reply to Gerald Ruescher
    TI__Mastermind 46460 points

    Gerald, Lennart,

    The DDR PHY in K2E has an automatic initialization sequence after reset release.  Since this was deemed to be non-compliant, the software initiated DDR interface initialization starts be a full reset of the controller and PHY.  Later in the initialization sequence, the JEDEC-defined SDRAM initialization sequence is initiated.  The SDRAM is required to operate properly after this sequence is executed.

    Tom

  • 0 in reply to Tom Johnson 16214
    Prodigy 160 points

    Hi Tom,

    To get your answer clear, is my following understanding right:

    1. The DDR PHY starts an initialization/reset sequence of the attached RAM right after the Reset of the K2E. Unfortunately this sequence does not comply with the JEDEC standard, as we also measured on our board. There is nothing we can do against this "wrong" rising edge.

    2. The second sequence, carried out by software, resets the DDR RAM again, now in compliance with the JEDEC standard.

    --> Are there any statements that guarantee that a valid Reset definitely "cures" the preceding sequence, in other words leads to a clean setup of the RAM, despite of everything going on in advance?

     

    Thanks, best regard

    Lennart 

  • 0 in reply to Lennart Siekmann
    TI__Mastermind 46460 points

    Lennart,

    Yes, that is the expectation.  The reset pin was added by JEDEC with DDR3/3L for the explicit purpose of providing a means to recover an SDRAM from and state back to the init stat.  The controller and PHY in the processor is also expected to be in a clean state after the PHY reset that is invoked by software at the beginning of the interface initialization sequence.

    Tom