AnsweredAssumed Answered

Avoiding redundant DDR2 configuration

Question asked by robh.mcs on Aug 1, 2013
Latest reply on Aug 2, 2013 by Harshit.Gaharwar

I'm developing an application on the SHARC ADSP21469 in CCES, and I'm wondering if anyone has found an easy solution to this problem: In my application code, I include the code PLLDDR2.c (from an example project) which sets up the DDR2 interface. It works well, and there are no issues with it when I set my build artifact to be a DXE and load the software image with the USB-ICE debugger.

 

However, if I set my build artifact to be a LDR so that I can produce a bootable PROM image, I run in to a problem. The PROM bootloader included in the ldr includes code to set up the DDR2 interface, which is fine, except that once the bootloader is finished and my application is run, my application calls the init function in PLLDDR2.c and sets up the DDR2 interface all over again. The issue is that because of this, I can't put any code or constants in the DDR2 memory, as what would happen is that the bootloader would setup the interface, then copy the code/constants in the RAM, which could then become corrupted when my application code sets up the DDR2 interface again.

 

So the bootloader needs to set up in DDR2 interface in order to work properly, but my application code needs to as well because if I'm loading a DXE via the debugger, no bootloader is run. Has anyone found an easy solution to this issue? Maybe attempting a read/write from the DDR2 before doing the setup?

Outcomes