• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 867 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.

AM1808+DDR2 system crash

Prad1
Genius 3825 points
Other Parts Discussed in Thread: AM1808

Hi,

We have few questions regarding DDR2 and AM1808.
I am sorry if these are repeated questions.

Our customer is using DDR2 with AM1808 and few of the custom
boards has system crash issue related to DDR2.(confirmed with a test program)

note:The DDR is configured in point-to-point, without any external termination.
The drive strength is set to weak as per the datasheet guideline.

Meanwhile we have few test results about the DDR2 behaviour as below.
Please let me know if there are any known reasons or general comments on this.

1.Before the System crash, the DDR memory seems fine but after the crash
the memory is unstable with constantly changing bits.
They see the data on the DDR changing constantly even when
the CPU and all clocks are OFF. But restores with a reset on DDR PHY.
Debugger is accessing memory directly through debug core.

MPU is in "abort" mode, and stuck in exception vector(s).
Usually the exception vectors 0xc, 0x10, 0x14.

2.After the crash, normal memory behavior can be recovered by resetting
DDR2 controller using DRPYRCR register. Bits are stable, and original,
uncorrupted memory reappears.

3.It seems all the custom board units show this exact behavior if they add 2.2pF
capacitance on DQS1 signal line. This is extremely low value, and should be
no problem. Simulations show S.I.is also well within spec even with 2.2pF.
A small bump is seen on the rising edge of DQS1 with increased capacitance.

4.Using full drive strength of DDR2 memory this bump "disappears" (due
to overshoot), and all units become stable, and can tolerate up to 4pF added load.

5.As mentioned in the AM1808 datasheet, the parallel termination is not allowed,
but the signal integrity improves with the parallel termination(based on the
simulation). What is the reason TI does not allow parallel termination.

Above observations indicates that the MPU DDR2 controller reaches some
kind of unstable state, which is recovered when the DDR2 PHY is reset.

Best Regards
Prad.

  • 0
    TI__Guru** 116100 points

    Hi Prad,

    What type of code are you running for testing & field ?

    non-OS (starterware) or linux ?

    Have you tried to reproduce the same problem on your working board ?

    How about the environment for both working and non-working boards ?

    Is there any difference ?

    Have you modified the code related to DDR on linux source if any ?

    2.After the crash, normal memory behavior can be recovered by resetting
    DDR2 controller using DRPYRCR register. Bits are stable, and original,
    uncorrupted memory reappears.

    How did you recovered the board to normal after crash ?

    Our customer is using DDR2 with AM1808,
    and few of the custom boards has issue(system crash) related to DDR2.

    What is the test program has been used ?

    Try to run "mtest" from u-boot for a long time.

    Provide your crash log which is generated from kernel.

    I would like to suggest that trying the starterware (non-OS) code on DDR for a long time and check whether you are seeing any issues while running the code.

  • 0 in reply to Titusrathinaraj Stalin
    Genius 3825 points

    Hi Titus,

    Thank you very much for the reply.

    Below are the few details about your questions,
    regarding the remaining questions I shall get the details from the
    customer and let you know.
    Can I send some of the details through mail? (my ID is pradeep_kumar@ktl-corp.co.jp)

    >non-OS (starterware) or linux ?
    The OS is LINUX and the OS & source code is from TI's DaVinci-PSP-SDK-03.22.00.02.

    >Have you tried to reproduce the same problem on your working board ?
    By chaning the value of RL in DDRPYCR1 register, they see the same behavior on working boards.

    >How about the environment for both working and non-working boards ?
    the environment for both the boards are same.

    I am sorry for the incomplete information.

    Best Regards
    Prad

  • 0 in reply to Prad1
    Genius 3825 points

    Hi Titus,

    Below are the details about the remaining questions.

    Have you modified the code related to DDR on linux source if any ?
    ->According to our understanding the code is same as the TI's PSP.

    How did you recovered the board to normal after crash ?
    ->They are using trace32 debugger and they are able to access the DRPYRCR register,
       so the board is recovered by resetting DRPYRCR register through the debugger.

    What is the test program has been used ?
    ->They are runing a simple linux test program without any peripherals(other than DDR) & without the application.

    Try to run "mtest" from u-boot for a long time.
    ->Unfortunately,they don't have the option to run the Bootloader in the current environment.
       They can use only the debugger. The bootloader itself is from the TI's PSP.

    Provide your crash log which is generated from kernel.
    ->As the system stops immediately, it seems there is no crash log from the kernel,
       moreover we believe this is a hardware(not software related) issue and kernel may not produce logs.

    I would like to suggest that trying the starterware (non-OS) code on DDR for a long time
    ->We are trying to find a right sample code to check only DDR2,
       but as you know, the current software is completely related to Linux and it would be
       difficult to port the StarterWare codes to the custom boards.

    I am sorry if this information is insufficient,
    please let me know if there is anything else required.

    Best Regards,
    Prad

  • 0 in reply to Prad1
    TI__Guru** 116100 points

    Hi Prad,

    Thanks for your detailed responses.

    Try to run "mtest" from u-boot for a long time.
    ->Unfortunately,they don't have the option to run the Bootloader in the current environment.
       They can use only the debugger. The bootloader itself is from the TI's PSP.

    I'm curious that you are working linux without bootloaders, and just running through debugger.

    Could you please try to run the linux through bootloaders stuffs ie flashing bootloaders into any kind of media (NAND/SPI/NOR) and try to execute from it and call linux kernel.

    Mean while I ask our hardware experts to look into this issue.

  • 0 in reply to Titusrathinaraj Stalin
    Genius 3825 points

    Hi Titus,

    Thank you.

    As mentioned by you, currently I am trying to test the DDR2 with a starterware (non-OS) code.
    Please let me know if there is any sample code to test AM1808+DDR2 on CCS.
    Is it possible to test through only the GEL file?

    Best Regards
    Prad

  • 0 in reply to Prad1
    Prodigy 130 points
    Hi Prad,
    Has your problem be solved or not?
    We have met with the same issue.
    It seems that "weak drive" can not work at all.
    Can you update your status?

    Thanks,
    Leo
  • 0 in reply to Leo
    TI__Mastermind 43660 points
    Hello Leo,

    I would request you to create a new thread with detailed explanation of your problem to get better attention.

    Regards,
    Senthil