DDRC Timeout while waiting for DEBUG_2 on LS1046A

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

DDRC Timeout while waiting for DEBUG_2 on LS1046A

749 Views
axegar
Contributor II

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 a number of boards (more than we are willing to tolerate) we get some failures which were originally attributed to bad eMMC devices. However, upon looking deeper into the issue, I can now say that I believe these failures are due to something related to the DDR4 bus between the LS1046A and the DDR4 devices. The specific error message is:

DDRC: Timeout while waiting for DEBUG_2

On CCS the error message I get is:

Cortex-A72: Core not responding

This seems to be related to the erratum A009803 as found in the target initialization file.

In order to debug this, using a good board (GB) I confirmed that I am able to read/write to internal and external memory using the CCS tool. Then I made the following changes:

1. removed the eMMC device

2. removed one of the 4x DDR4 mem devices

After rework 1 above, I am still able to initialize the board and read/write to internal and external memory as expected via CCS tool.

After rework 2 above, I am now able to induce the same failure message as seen on the bad boards. And now, I get the "Core not responding message" and I am unable to talk to the device.

Questions I have / would like some help with:

1. Is there a way to bypass the DDRC init so that I can still talk to the LS1046A via JTAG to assess health status?

2. Is there a way to configure the DDRC to only talk to 3 out of 4 devices i.e. in essence ignore one or more DDR4 devices during init?

3. what are some status/error register I can look at to assess health of the LS1046A, DDRC, and DDR4 devices?

4. why does the Diagnose Connection inside the CW IDE check the marks the "Run target initialization script" step with a green checkmark, when it actually reports a Timeout? Is this the expected behaviour?

Any suggestions or ideas would be much appreciated.

Thanks

Axel

Labels (1)
Tags (4)
0 Kudos
Reply
2 Replies

721 Views
yipingwang
NXP TechSupport
NXP TechSupport

1. In target initialization File, in function "run_init_file", please comment line "Init_DDRC(DDR_freq)".

 

2. No this configuration.

3. Please refer to the following document.

https://community.nxp.com/t5/CodeWarrior-for-QorIQ-Knowledge/DDR-Bringing-up-and-validation-with-QCV...

4. It means there is problem with DDR controller initialization. 

545 Views
axegar
Contributor II

Hi @yipingwang ,

Thanks for your help. You were absolutely right, it seems to have been a configuration issue only at the 1600MT/s DDR speed. 

In other word, during boot up when we have to use the default DDR configuration, we had some timing issue. I have now fixed this and things seem much more stable now.

Running through a number of files at the factory to truly validate the fix.

Thanks for your help

Axel

 

0 Kudos
Reply
An error has occurred when reading existing sub-variable "Language_PG_Configuration"; see cause exception! The type of the containing value was: extended_hash+string (lithium.coreapi.webui.template.models.NamedValueByNameTemplateModel wrapped into f.e.b.StringModel) ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign redirect_lingo_page_url = web... [in template "language_macro_header.ftl" at line 173, column 1] - Reached through: #include "language_macro_header.ftl" [in template "Language_translator_Dashboard" at line 3, column 1] ----