This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

6678 + software reset = DDR3 problem?



Hi.

I have custom 6678 board. To emif64 attached 4x16 DDR3-chip + 1 DDR3-chip for ECC.

My goal is boot code from tftp and run it on dsp. But i have a problem with reuse NIMU: after POR network aplication load and run correctly, but after second run NIMU initialisation fails.

I am try use DSP software reset to avoid this problem.

Boot mode = i2c boot. In i2c-rom writed code like:

main()

{

for(;;);

}

my steps are:

1. Launch CCS 5.3, start debug session, run Gloabl_defaul_setup from gel-file. At this point all work whell. I can load programm, read and write DDR3 memory and so on.

2. Write to PLLC reset sequence (I try set reset type to software and  to hardware). CCS change PC to 0x20B00000. At this point i still can load programm, browse DDR3 memory and all looks whell.

3. In CCS debug session I push F8 to run RBL(0x20B00000) and stop dsp after several seconds. PC stay in infinity loop from my i2c-boot application. At this point while trying to read the memory I can see that the values ​​in it are stable and memory somehow works. But when trying to write to memory data is written incorrectly. Most often, the 64-bit word divided into 2-3 parts, each of which is stored in different locations.
For example: when writing 0x1234567890ABCDEF constant at 0, 1234 will appear in the address 16, the 567890AB at address 2 (as it should), and the  CDEF at address 30.

According to the documentation, soft reset should not interfere with the operation DDR3 and PCIe, but looks like after RBL work, DDR3 controller loses leverage settings so different DDR3-chip sampling data at wrong point.


Question: how can restart the 6678 without data loss in the DDR3?