LS1046ARDB DDR4 Memory Configuration

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

LS1046ARDB DDR4 Memory Configuration

Jump to solution
2,860 Views
Daves_Garage
Contributor IV

Hi,

Trying to debug a bare-board project on an LS1046ARDB, I followed these steps...

0 Kudos
Reply
1 Solution
2,799 Views
Daves_Garage
Contributor IV

So the solution to this problem is the initialization of the DDR memory, which is sort of what the Connection Diagnostics terminal window was trying to tell me - It couldn't write data at address 0x80000000...that's because the DDR wasn't setup correctly.

Seems odd to me that the initialization script that comes with the Target Connection specifically called LS1046ARDB doesn't work with the LS1046ARDB...  just sayin'...

Anyway, running the DDR utility on the LS1046ARDB, and using it to generate the ddrCtrl_1.py file that it can generate, then copying the content of that file into the initialization script for the Target Connection, and running the connection diagnostics again, generates this result:

Daves_Garage_0-1657573937735.png

 

Problem solved...

View solution in original post

0 Kudos
Reply
7 Replies
2,723 Views
Daves_Garage
Contributor IV

Richard,  Sorry just getting around to seeing this now... I've played around with Code Warrior so much now, I've finally decided it sucks, so the only thing I'm using it for is debugging (when I get to that stage).  For now, I've found life to be much simpler to work from my VM running Ubuntu 20.04.

I downloaded the SDK 21.08 and literally just ran the example make (of course there's a ton of stuff you have to install BEFORE you can simply run this make command, which took forever to figure out)...

It generated everything I needed to reflash the RDB.  Then, from windows, I manually ran GDB, modified the python script that sets up the TAP module, and manually flashed the QSPI memory with the newly generated files from linux... works like a charm...

I can show you the steps if you like...  one thing I did like was the memory configuration utility within Code Warrior; I plan to use it on our new hardware when it's ready.

-Dave

 

0 Kudos
Reply
2,714 Views
richardadams
Contributor III

Agree with you assessment of the high quality of CodeWarrior, but I would also extent that assessment to the technical support. You had mentioned how it was taking you a couple of days to get a response. Me experience has been more like a couple of weeks if at all before I get a response. And it usually a RTFM response.

Unfortunately I'm still stuck at getting the DDR controller to successfully initialize. I've gone through the process of running the DDR configuration tool then taking the generated code and incorporating it into the debugger initialization script. It gets a little better each time. Currently the best I've gotten is the controller will complete initialization, but will have an Auto Calibration Error (ACE). I can't haven't found any indication of what to do to resolve this error except the words of NXP wisdom "correctly configure you DDR controller". I thought I could get the configuration close enough and let the DDR Validation tool fine tone the configuration, but The Validation tool won't run. It starts but fails the first test of each scenario because of the DDR controller having the ACE error set.

We'd like to get NXP to review our schematics and verify our design, but the haven't given any response in several weeks since we sent then the schematics. There are a couple of items I'd like to get NXP to confirm or deny. One is we are using a single 16 bit memory part. This should work but will require the DDR controller to issue two 16 bit read from memory on each 32 bit memory access.. The second is the DQ masking (data bit swizzle) the HW board designer selected a bit mapping not supported by the LS1043. So we don't do any bit swizzeling in the DDR controller. We would like to get someone at NXP to confirm or deny. The company is trying to contract NXP Engineering Services, but I think they are having trouble getting NXP to respond to a request for quote. It sucks being a small volume customer.

0 Kudos
Reply
2,645 Views
Daves_Garage
Contributor IV

wow... this really does suck.  lol, just realized my reply is 2 weeks out from your last reply... I've been elbow deep in this processor working out the finer details of the RCW, the DTS file, and the DDR4 init file for our new board.  Surprises me how long it takes to get things figured out.

Good luck.  If I have one of those "ah-ha" moments, I'll share here...

0 Kudos
Reply
2,800 Views
Daves_Garage
Contributor IV

So the solution to this problem is the initialization of the DDR memory, which is sort of what the Connection Diagnostics terminal window was trying to tell me - It couldn't write data at address 0x80000000...that's because the DDR wasn't setup correctly.

Seems odd to me that the initialization script that comes with the Target Connection specifically called LS1046ARDB doesn't work with the LS1046ARDB...  just sayin'...

Anyway, running the DDR utility on the LS1046ARDB, and using it to generate the ddrCtrl_1.py file that it can generate, then copying the content of that file into the initialization script for the Target Connection, and running the connection diagnostics again, generates this result:

Daves_Garage_0-1657573937735.png

 

Problem solved...

0 Kudos
Reply
2,757 Views
richardadams
Contributor III

@Daves_Garage glad to hear you got it working. I didn't have an issue with the LS1043RDB initialization script,  but I think the issue with the LS1046RDB is the DDR is a DIMM, while the LS1043RDB it's direct memory. The 46's may have different DIMMs on them when they get shipped, and that may require an update to the DDR controller initialization. It would be nice for NXP to say something like. The debugger initialization script was written with DIMM part number xxxxxxx. If your RDB has a different DIMM then the DDR controller initialization may need to be updated in the debugger initialization script. Follow these steps to perform this task

 - xxxx

- yyyy

That would have been nice ---  "Just saying"

By the way what steps did you follow? I have a LS1046RDB also, but it's not my focus right now. My focus is the ls1043 custom board which I haven't been able to configure the DDR correctly yet. I did run a quick test on the LS1046RDB and it fails the DDR memory test, and I suspect it's the difference in the DIMM modules (one the script was written for and the one that's installed)

 

 

2,843 Views
Daves_Garage
Contributor IV

Made a little progress on this, but still having an issue with the initialization script in the Target Configuration.

Rerunning the connection diagnostics, I get this:

Daves_Garage_0-1656691158924.png

 

Daves_Garage_1-1656691180799.png

 

I could sure use some help with this.

 

0 Kudos
Reply
2,859 Views
Daves_Garage
Contributor IV

woops, for to post the steps... Here they are:

Before flash programming with CodeWarrior, you must create a "Hello World" ARMv8 bare-board project and use it to connect.
From Workbench, follow these steps:

Setup a project


  • Select File->New->CodeWarrior Stationry, then select the "Hello World C Project"
    • Give the project the name "HelloWorld"
  • Daves_Garage_0-1656024350342.png

     

  • Once created, build it
  • Daves_Garage_1-1656024350343.png

     

Setup a target connection


  • Select Windows->Show View->Other, then select Debug->Target Connections
  • Right click on LS1046A_RDB and "Duplicate" it - it will offer the name "LS1046A_RDB (1)"; use it
  • Double click this configuration from the list now (it's bold)
  • Daves_Garage_2-1656024373819.png

     

  • Set the IP address to 192.168.0.15 for the TAP module
  • At the bottom of the window, select "Target Initialization File" tab, which opens up the code used to initialize the system
    • Change USE_SAFE_RCW = False to USE_SAFE_RCW = True
    • this is important, as there is no RCW yet in bare metal project Looks like this:
    • Daves_Garage_3-1656024373819.png

       

  • Verify you can find the TAP module by pressing the flashlight icon in the "Target Configuration" tab
  • Daves_Garage_4-1656024424716.png

     

  • A successful connectioin will show this:
  • Daves_Garage_5-1656024424716.png

     

  • Select the connection under "Connection Details", and press "OK" button
  • use CTRL-S to save the configuration

Configure the target launch configuration


  • Select Run->Debug Configurations->GDB Hardware Debugging->HelloWorld, then on the tabs select Debugger.

  • Under the section "Target Connection Configuration", check all 3 boxes, and for the Configuration file, use the drop down to find the one you just created above (LS1046A_RDB (1)) and select it

    • If you are having issues with DDR memory, the whole "verify memory after download" is going to fail, since debugging occurs in DDR memory - in otherwords, if your DDR memory isn't configured right, the debugging session won't be working...
  • Daves_Garage_6-1656024460284.png

     

  • For "Core:", select the first core (Cortex A72#0)

  • Finally, select both "Synchronize with breakpoints" and "Force thread list update" boxes

  • Your final configuration should look like this:

  • Daves_Garage_7-1656024460284.png

     

  • SAVE IT by pressing the "Apply" button

Debugging (not working)

  • Start debugging by pressing the "Debug" button
  • Daves_Garage_8-1656024492348.png

     

  • USE CONNECTIOIN DIAGNOSTICS

 

  • At the top right corner of the "Target Connections" window, there is an icon that looks like this:
  • Daves_Garage_9-1656024512622.png

     

  • Press it, and open the Connection Diagnostics terminal window to see what's going on...
  • Daves_Garage_10-1656024512622.png

     

... and this is as far as I get...

I could use some help

 

0 Kudos
Reply