DDR Read/Write issues using CCS on an embedded LS1046A custom carrier board

[axegar]

Hello,

I am using an LS1046A on a custom carrier board. We have these boards shipping and running in the field, however there are some lingering manufacturing issues I am looking into.

On one of those boards, I have run into a situation where using CCS to peek/poke at mem address I have found the following interesting observation.

I can read and write at address 0x82000000 without issues or so it seems. However, if I write 0xDEADBEEF to that address and read it back, I consistently get 0x21ADBEEF.

These are the specific commands I am using

• read memory
  • ccs::read_mem 33 0 0x82000000 4 0 2
• write 64 bits

  • ccs::write_mem 33 0 0x82000000 4 0 {0xDEADBEEF 0xDEADBEEF}

I can write 0x00000000, 0xFFFFFFFF, 0xDDDDDDDD, 0xEEEEEEEE, 0xA5A5A5A5, 0x5A5A5A5A and they all return the expected values. Only  0xDEADBEEF seems to return 0x21ADBEEF, which is unexpected.

I originally thought this was a manufacturing issue, however, after the sequence of test patterns above, I have to rule out that hypothesis.

Does anyone have any intuition or explanation as to what might be causing this? Is this a protection memory address? Is this a bug in CCS/CWTAP? Are there any erratas related to this?

Any suggestions would be much appreciated.

[valokuvaaja]

@axegar 

0x21 = b0010_0001, 0xDE = b1101_1110

So, the bits in that nibble are flipped for some reason. 
If I were you I would run the "Mem Tester" and "Stress Tests" scenario from the CodeWarrior using CW-TAP.
If it shows only on one board, then it seems likely an issue only with certain SDRAM chips on this particular board.

[axegar]

Hi @valokuvaaja,
Thanks for the input. Yes, I suspect either a processor or mem related manuf issue.
My next step is to run the mem validation tests you suggested, but i am running into issues connecting to my TAP controller (only when attempting to run QCVS). Otherwise, I am able to use the TAP controller when programming eMMC or using CCS console.
Any good resources you can point me to that talk about the process of establishing a QCVS link and how to do that process?

[yipingwang]

Please create a QCVS DDR project with "reading from target" method.

If you encounter problem to connect CW to the target board,

In CodeWarrior IDE, when connecting to the target board, the CCS console will pop up in the Windows task bar, please open it type "log v", then connect to the target board again, the low level CCS log will be printed, please capture it to me.

[yipingwang]

DDR controller configuration section in CodeWarrior initialization file is only suitable for LS1046ARDB demo board, you need to customize this file according to your custom board.

Please use QCVS DDRv tool to connect to your custom board to do validation to get the optimized DDR controller configuration parameters, then use them in CW initialization file and ATF software.

Please refer to DDRv user manual https://www.nxp.com/docs/en/user-guide/QCVS_DDR_User_Guide.pdf

The customer needs to create a DDR QCVS project according to the custom board.

If DIMM is used on the customer’s board, there is SPD on the target, please select “Read SPD” in DDR configuration panel when create QCVS DDR project.( example: https://community.nxp.com/t5/Qonverge-Knowledge-Base/DDR-Controller-Configuration-on-LS2085-LS2080-B...)

If the customer uses Discrete DDR, in DDR configuration panel, please select “Configuration mode” as “Auto configuration” and “Discreate DRAM”, and configure board and DDR controller related settings according to the custom board. Then in the project, please configure DDR related configuration parameters in “properties” panel according to the DDR data sheet.

Then use QCVS DDRv tool to connect to the target board to do further optimization and validation.

After successful validation, please click Project->Generate Processor Expert Code to get the optimized DDR controller configuration parameters in file ddr_init1.c, and use it to modify ATF source code plat/nxp/soc-ls1046a/ls1046ardb/ddr_init.c.

[axegar]

Hi @yipingwang ,

I think I have figured out the immediate issue which is the bit flips.

It was due to the target initialization file.

It seems that the tcl target init file I was using inside CCS must have some timing issues because I can induce the same behaviour on an otherwise good board is I use this init file. However, if I first go into CodeWarrior IDE and run the Diagnose Connection, which uses a Python target init file, then I am able to read/write values as expected to both internal and external memory.

While this solves my immediate question, it means that I can now debug the actual issue I started to investigate to begin with which is related to this error message and erratum A009803:

DDRC: Timeout while waiting for DEBUG_2

See attached image .

But let me close this bug ticket and open a new one specific to that other issue.

Thanks!

[axegar]

Hi @yipingwang,
Yes we do have a custom init file that has been working fairly well. We have gone through the entire QCVS design and validation process and updated our timing params as needed.
However, we do see these lingering issues during manufacturing which we had attributed to other causes such as power and eMMC devices, but now, I am starting to think that they are likely mem or processor related.

Is there a good set of registers I can query via CW TAP to establish the sanity of my LS1046A?
Could you point me to a good resource to look at for this?