Testing DDR in a evaluation board using Codewarrior

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

Testing DDR in a evaluation board using Codewarrior

Jump to solution
1,361 Views
jesusgonzalez
Contributor I

Hi,

 

We need to prepare a set of test to validate the design of MPC8306 CPU based board. One of these test is the checking of DDR. Until we are able to test in the final board we are using a MPC8306KIT evaluation board with the next DDR memory map:

Range Start: 0x0000_0000

Range End:  0x07ff_ffff

Size: 128M.

 

The information above is extracted from the "BSP targeting the Freescale MPC830xSOM Board User's Guide" document.

 

A task has been created in order to perform this test. A snapshot with its parameters follows:

 

13595_13595.jpgtest_ddr_mpc8306_som_kit.JPG.jpg

Use target CPU is marked as we have read in documentation this option is quite faster than if host PC using CodeWarrior has to execute it.

 

 

As requirement we need to check whole 128MB DDR memory so theoretically in the field "Test Area Size: 0x" a value "07FFFFFF" should be placed. If we do so without marking the "Use Target CPU" the test took more than 24 hours and the operation didn't finish, so we decided to cancel it (we don't know if something was happened but we don't get any feedback and it looks like 24 hours were too much). So we decided to take a different approach.

 

We realized that it was necessary to make the test in, almost, two different tests. First one, without "Use Target CPU" marked to test the part of memory where "Use Target CPU" algorithm will be placed and a second one to test the rest of the memory marking the "Use Target CPU" option as we have the hope this test won't take 24 hours. But if we do so, Codewarrior displays the following error:

13596_13596.jpgresult_ddr_test.JPG.jpg

 

We have found that values over "038FFFFF" produces an error of the type above.

 

Anyone has the same problem? What are we doing wrong? Do you know a better method to test the DDR using Codewarrior?

 

Any help will be really apreciated.

Labels (1)
0 Kudos
1 Solution
844 Views
lunminliang
NXP Employee
NXP Employee

See below FAQ solution about this message:

Solution:

   CodeWarrior's Hardware Diagnostics Memory Tests has two options for how it exercises target RAM: Host-controlled via JTAG (USB TAP, Ethernet TAP) or Target CPU controlled. The host-controlled method does each write and verify one byte/word/long-word at a time directly from the CodeWarrior IDE. This method is very reliable because it requires no resources on the target. The Target CPU method uses a small block of target RAM to host the memory-test program downloaded to the target. This method is much, much faster but requires some portion of target memory to be reliable. The "magic number" error reported here is a result of using the Target CPU method.

When running Memory Tests using target RAM to host the memory-testing program, CodeWarrior downloads an algorithm (target application) into the Target Scratch Memory (defined in the Memory Tests configuration panel.) This is similar to the Flash Programmer's operation, which uses an algorithm (target application) to do the programming/erasing of Flash memory.

After this algorithm is downloaded to the target, CodeWarrior reads back what it wrote in the target scratch memory (similar to verify memory writes when downloading an ELF file with a debugger - stationery project). The first 4 bytes that are written to the target scratch memory represent a "magic number". If the magic number read back from the target does not match the original number, it means the algorithm was not downloaded correctly.

The solution is to go back to using the host-controlled method by disabling the Use Target CPU option, get these memory tests to successfully validate roughly 128Kb of target RAM, and then use that validated memory space to host the memory-test algorithm.

View solution in original post

0 Kudos
1 Reply
845 Views
lunminliang
NXP Employee
NXP Employee

See below FAQ solution about this message:

Solution:

   CodeWarrior's Hardware Diagnostics Memory Tests has two options for how it exercises target RAM: Host-controlled via JTAG (USB TAP, Ethernet TAP) or Target CPU controlled. The host-controlled method does each write and verify one byte/word/long-word at a time directly from the CodeWarrior IDE. This method is very reliable because it requires no resources on the target. The Target CPU method uses a small block of target RAM to host the memory-test program downloaded to the target. This method is much, much faster but requires some portion of target memory to be reliable. The "magic number" error reported here is a result of using the Target CPU method.

When running Memory Tests using target RAM to host the memory-testing program, CodeWarrior downloads an algorithm (target application) into the Target Scratch Memory (defined in the Memory Tests configuration panel.) This is similar to the Flash Programmer's operation, which uses an algorithm (target application) to do the programming/erasing of Flash memory.

After this algorithm is downloaded to the target, CodeWarrior reads back what it wrote in the target scratch memory (similar to verify memory writes when downloading an ELF file with a debugger - stationery project). The first 4 bytes that are written to the target scratch memory represent a "magic number". If the magic number read back from the target does not match the original number, it means the algorithm was not downloaded correctly.

The solution is to go back to using the host-controlled method by disabling the Use Target CPU option, get these memory tests to successfully validate roughly 128Kb of target RAM, and then use that validated memory space to host the memory-test algorithm.

0 Kudos