Hi,
Trying to debug a bare-board project on an LS1046ARDB, I followed these steps...
Solved! Go to Solution.
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:
Problem solved...
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
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.
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...
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:
Problem solved...
@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)
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:
I could sure use some help with this.
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:
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
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:
SAVE IT by pressing the "Apply" button
... and this is as far as I get...
I could use some help