topic Re: Executing from LPDDR2 in Vybrid Processors

Executing from LPDDR2

chrispage — Thu, 21 Nov 2013 21:02:05 GMT

I am currently using a Micron LPDDR2 (MT42L32M16D1) part. I have it configured and have been able to run a memory test executing from internal SRAM that can write and read from the LPDDR2 memory without any errors. When I go to execute out of the LPDDR2, I am receiving errors(chip is going off into the weeds) upon execution of any instruction that utilizes the stack(push, bl, etc.). If I adjust the TBST_INT_INTERVAL from 2 to 4, I am able to use a debugger and step through these instructions without error, but if I attempt to run without stepping, I see the crash again. Adjusting the interval more in either direction does not help (if anything makes it worse). Any idea which DRAM configurations/settings would be causing this problem? Thanks.

Re: Executing from LPDDR2

jiri-b36968 — Wed, 27 Nov 2013 14:55:17 GMT

Hi Chris,

please look at Re: Re: VF5xx / Example of LPDDR2 Configuration

/Jiri

Re: Executing from LPDDR2

chrispage — Wed, 27 Nov 2013 17:04:11 GMT

I have looked at the example and have been able to read/write the memory when executing from internal SRAM. I am running at 400MHz instead of 200MHz, so many of my parameters have been changed based on my LPDDR2's data sheet. I am looking more specifically for areas to investigate(which register configurations I should be focusing on) as to why reading/writing to memory from internal memory works yet executing from the external memory gives me errors when running at full speed. As well as more information as to what TBST_INT_INTERVAL matches up with on memory data sheets since that is the only parameter adjustment that seems to cause a slight change in what I am seeing.

Thanks,

Chris

Re: Executing from LPDDR2

naoumgitnik — Tue, 03 Dec 2013 00:13:10 GMT

Hello Chris, Do you mean your problems started when you increased the LPDDR2 speed from 200 to 400 MHz? Regards, Naoum Gitnik.

Re: Executing from LPDDR2

chrispage — Tue, 03 Dec 2013 16:29:04 GMT

I have not tried 200MHz yet, but I am in the process of giving it a try right now to see if the same problems exist. Was executing out of the LPDDR2 tested with the 200MHz code sample that was provided? Also, are there any other register changes needed for the example code to run (for example clock register settings).

Re: Executing from LPDDR2

chrispage — Tue, 03 Dec 2013 21:46:50 GMT

Unfortunately running at 200MHz using the example code did not work at all. The parts must be different enough that the example code is not compatible.

Re: Re: Executing from LPDDR2

naoumgitnik — Tue, 03 Dec 2013 22:50:39 GMT

Chris,

Attached are settings for our validation board - may you use them, please?

Regards, Naoum Gitnik.

Re: Executing from LPDDR2

naoumgitnik — Wed, 04 Dec 2013 23:43:38 GMT

Hello Chris,

Please, also take a look at the Processor Expert tool released for Vybrid - on the product pages, under Software and Tools -> Updates and Patches.

I don't have any personal experience of it, but it claims to have a DDR configuration wizard included.

Regards, Naoum Gitnik.

Re: Executing from LPDDR2

chrispage — Thu, 05 Dec 2013 14:07:06 GMT

Thanks for all the information. I am currently trying various configurations to try to narrow down configurations in which this problem is being seen and I will post those once I have completed all my testing.

Re: Executing from LPDDR2

chrispage — Thu, 05 Dec 2013 20:40:07 GMT

I have tried matching up my configuration with all of the available examples and I still see the original problem. The only configuration parameter that seems to effect the way the error is seen is TBST_INT_INTERVAL. Do you have any specifics about what this configuration parameter does? The reference sheet is not very specific. Also is there any way I could get the rest of the code that was used when testing these DRAM configurations to see if there is anything we are missing? Do you know if executing out of LPDDR2 has been tested?

Re: Executing from LPDDR2

naoumgitnik — Fri, 06 Dec 2013 00:09:52 GMT

Hello Chris,

While working on this issue, I got the following advice from one of my colleges who is more DDR/Vybrid expert than me:

"I'd recommend trying to do some memory tests using the DMA to read the memory with the SSIZE set to 32-byte. That way you make sure that you are using the full burst of data from the DDR and getting back the expected results. Hope it helps."

Regards, Naoum Gitnik.

Re: Executing from LPDDR2

chrispage — Fri, 06 Dec 2013 13:38:41 GMT

I will try this, I noticed there is a DMA test in the example code that has been posted, but it is using a file dma.h to help set up the DMA. Do you have dma.h that you could post so I don't have to recreate it?

Thanks,

Chris

Re: Executing from LPDDR2

juangutierrez — Fri, 06 Dec 2013 18:10:12 GMT

alejandrolozano would you have the dma.h file for the lpddr2 project you posted on https://community.freescale.com/message/364994#364994 that you can share, please?

Re: Re: Executing from LPDDR2

juangutierrez — Sat, 07 Dec 2013 01:46:10 GMT

Hi Chris

Find attached the dma.h file

Re: Executing from LPDDR2

GordyCarlson — Sun, 08 Dec 2013 15:49:49 GMT

I'm the local Freescale FAE, supporting this customer. I went onsite to customer this week. Here is additional background info. I sent this to Naoum and Jiri via email, they request this be posted within the Community thread for continuity.

- Customer runs its LPDDR at 300Mhz. They see memory failures and system lockup whenever a stack pop/push occurs when executing from LPDDR.

- These failures do not occur when they execute code or tests from internal Vybrid memory.

- We (Local Arrow DFAE and I) advised customer to relocate their stack and re-test. It fails regardless if the stack is internal or external
in LPDDR when executing from LPDDR. Its works fine when stack is internal OR external if executing from internal memory.

- Jiri/Naoum provided LPDDR settings for 200Mhz, and also from our 400Mhz LPDDR validation board. Customer is study those for differences with their settings.

- Is there a difference in how a stack instruction cycle works in LPDDR from a memory system handshake point of view? That’s the only time it fails. I don’t think so, but it seems unusual that all other instructions execute fine from LPDDR and moving the stack internal or external doesn’t cause a failure, only the external stack pop/push instruction execution does.

Actions requested

--------------------------
** Customer asks if we can provide the complete codebase for the validation code….ie…PLL settings/general init files……as perhaps their problem is in a system setting they overlooked that is outside the LPDDR init values.

** Customer asks if we have run Linux from LPDDR memory? Or did we just run memory tests (executing from internal memory) on our LPDDR validation board?

** Can you provide schematics for our LPDDR Validation board? I have some from a couple years ago, not sure if they are the current rev. We will compare this to customers LPPDR schematic.

Re: Re: Executing from LPDDR2

naoumgitnik — Mon, 09 Dec 2013 20:26:53 GMT

Hello Everybody,

Attached are:

Excerpt from our LPDDR2 Validation board schematic,
DDR controller tuning document (just in case).

Unfortunately, based on what I learned from the SW Apps people, I am afraid this is all we can can help with, as of now; and the reason is that, based on our market observations, Vybrid customers are using DDR3 way more frequently that LPDDR2, so, with our limited resources, the department's focus is on the former - boards, code examples, etc. For the latter, though, we have only run validation tests, but not really beyond that point.

Sincerely yours, Naoum Gitnik.

Re: Re: Executing from LPDDR2

billpringlemeir — Mon, 09 Dec 2013 21:26:18 GMT

The SDRAM runs lots of different cycles (types of access). TBST_INT_INTERVAL is the bits in DDRMC_CR13? Wikipedia has a nice chart of the different commands. You can alter things by turning on/off the cache. Your stack access for instance, maybe the first write access. A back to back read/write can present problems, etc. I had issues with another Freescale CPU and it only manifested when people did SSH transfers over the FEC DMA. Ie, only certain data patterns and access cycles would trigger the problem. The ARM stm and ldm instructions can be used in memory test code to simulate the SDRAM bursts that would be possible with a cache turned on. If you have gcc for the test code then,

    register ulong t1 asm ("r0")  = 0;                              \
    register ulong t2 asm ("r4")  = t1 + incr;                      \
    register ulong t3 asm ("r6")  = t2 + incr;                      \
    register ulong t4 asm ("r8")  = t3 + incr;                      \
        /* Run an entire burst line. */                             \
        __asm__ (" stmia  %[ptr], {%0,%1,%2,%3}\r\n" : :            \
                 "r" (t1), "r" (t2), "r" (t3), "r" (t4),            \
                 [ptr]"r" (start + (addr<<2)) : "memory") \
        /* Read four 32 bits values. */                             \
        __asm__ (" ldmia   %[ptr], {%0, %1, %2, %3}\r\n" :          \
                 "=r" (t1), "=r" (t2), "=r" (t3), "=r" (t4) :       \
                 [ptr]"r" (start + (addr<<2)));

Maybe helpful in your IRAM test code to simulate some different DDR transfers. Most ARM compilers will generate the stm or ldm instructions when accessing the stack. The code pre-fetch hardware may only get a few words at a time and for certain it will only be in read mode.

The TBST_INT_INTERVAL is just saying how many burst to run in a row. Note, that this usually has to match some configuration of the DDR; there are special configuration cycles that you run to configure the DDR with the address bits (load mode registers at the wikipedia link).

Check the IOMUX settings for the DDR pins. The voltages are different for LPDDR and I don't see in the manual where this will be set. However, the memory will often function even if these values are not set properly. As well the Asynchronous/Synchronous clocking has to be set properly and depends on the CORE clocks.

The Micron DDR3 ZQ calibration tech note maybe of interest. Both the LPDDR2 and DDR3 can use this scheme and it seems to be supported by Vybrid DDRMC_CR66+ as well as 34.6.14. DDRMC_CR132+ seem like register that need to be tweaked per board; depending on PCB layout. All of the DDRMC_PHYSxx seem like places to search; try the memory test with different values and look at register like DDRMC_PHY29 to see what the controller is setting delays to. I would work on getting a SDRAM test that fails; random address and data are useful to try and exercise all transitions/cross-talk. Just because one type of access works, doesn't mean they all will.

Re: Re: Executing from LPDDR2

juangutierrez — Mon, 09 Dec 2013 22:27:58 GMT

I just sent you a direct message about some code I found, I don't know if that helps, but seems to have some code related to LPDDR2.

I have neither tried nor tested. Just sharing in case.

Re: Re: Executing from LPDDR2

naoumgitnik — Mon, 09 Dec 2013 23:58:31 GMT

Just a comment - this code is posted on the Freescale-internal Vybrid_FAE support forum in the thread discussing LPDDR2 settings.

/Naoum.

Re: Executing from LPDDR2

tomsaluzzo — Tue, 17 Dec 2013 17:42:19 GMT

Chris Page is having problems posting to the community, so I am posting this on his behalf.

I have finally been able to get the LPDDR2 working with a DMA memory test. The stack problems look to be solved when caching is disabled. It ended up looking like it was a burst problem. I am now at the point that once caching is enabled, I am still seeing problems. Once I have enabled caching (instruction and data), a "bx lr" instruction to return from the function that enabled caching seems to just increment the program counter and not actually branch (this works on the DDR3 but not on the LPDDR2).

Are there any memory settings that would affect caching or are there any cache controller settings that need to be configured differently for LPDDR2(running at 300MHz) vs DDR3(running at 400MHz)?