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.

DM37xx memory error

Other Parts Discussed in Thread: DM3730

HI All

        we are use DM3730, use MICRON mcp 4Gb + 4Gb, We produce 200 board,70% of the board is good, 30% of the board is bad,The following is a description of the problem:

(1).Open UMS function of Android OS;
(2).Copy a big size file(1G) from PC to SD card via OTG;
(3).Close UMS function;
(4).clear DM3730 memory cache;
(5).Open UMS again;
(6).Use HEX compare tools "Beyond Compare 3" to compare the data read from SD card to PC's source file, if they 100% the same, we define it OK, otherwise, it's failed.

(7). Bad board operation android application appear in the kernel crash, print kmem_freepages, drain_array, Good board operation android application is ok.

The following is the method we tested:

(1) Reduce core dpll frequency,From 200MHZ to 166MHZ,some board is ok,some board is failure,Then from 166MHZ to 133MHZ,All of the board are successfully(bad board is ok).

(2) We modified the omap-hsmmc.c drive to DMA mode to CPU, then the test is successful.

(3) We MPU frequency is fixed at 1G->800MHZ->600MHZ test, the problem also exists.

(4) We replaced the board of the MCP, to be tested again and found the problem followed by MCP.

For the random system crash->Therefore, According to our analysis, when the DMA read and write large amounts of data, LPDDR running at full speed, but the CPU to read and write large amounts of data, LPDDR running at half-speed. please help me,thanks.


  • We use the DM3730 CUS package,xloader uboot settings are OK for the memory, address pin A0-A13, CPU to the DDR layout distance 1600mil, our early version of the hardware, CPU to the DDR layout from only 900mil, only four bad board.

  • We now use the rowboat 2.6.32 kernel, upgrade to 2.6.37, the problem still exists,But the strange thing is that we tested in uboot(ITBOK) DDR no errors.

  • somebody help me,thanks

  • I think it's the signal  integrity problem  result from bad DDR layout. Maybe you can check it .  And i don not think that there is a software solution.

  • I met similar phenomenon. Use Micron 4Gb +4Gb. Some of the board kernel crashed after running a couple of hours.

    We set the ddr register as datasheet, and ddr length tolerance is 100mil.

    The log such as following:

    [<c00ab174>] (anon_vma_prepare+0x68/0x94) from [<c00a3520>]
     (handle_mm_fault+0x124/0x594)
     [<c00a3520>] (handle_mm_fault+0x124/0x594) from [<c003e930>]
     (do_page_fault+0xdc/0x1c4)
     [<c003e930>] (do_page_fault+0xdc/0x1c4) from [<c0037278>]
     (do_DataAbort+0x34/0x94)
     [<c0037278>] (do_DataAbort+0x34/0x94) from [<c0037e20>]
     (ret_from_exception+0x0/0x10)
     Exception stack(0xd79e7fb0 to 0xd79e7ff8)

  • hi, guys. 

    we have met this issue after we changed the TC Priority and we get :

    VTHPro        D c0307fc8     0  1551      1 0x00000000

    Backtrace:

    [<c0307cd8>] (schedule+0x0/0x380) from [<c03080a4>] (io_schedule+0x4c/0x80)

    [<c0308058>] (io_schedule+0x0/0x80) from [<c0070570>] (sync_page+0x40/0x48)

     r5:c41a3d6c r4:c41a3d6c

    [<c0070530>] (sync_page+0x0/0x48) from [<c0308970>] (__wait_on_bit_lock+0x5c/0xa4)

    [<c0308914>] (__wait_on_bit_lock+0x0/0xa4) from [<c0070508>] (__lock_page+0x6c/0x7c)

    [<c007049c>] (__lock_page+0x0/0x7c) from [<c00706c4>] (find_lock_page+0x50/0x78)

     r6:00000117 r5:c1b385a4 r4:c046b960

    [<c0070674>] (find_lock_page+0x0/0x78) from [<c0070f08>] (filemap_fault+0x234/0x408)

     r7:00000117 r6:c4e20a80 r5:c1b385a4 r4:00000000

    [<c0070cd4>] (filemap_fault+0x0/0x408) from [<c00842c4>] (__do_fault+0x54/0x3f8)

    [<c0084270>] (__do_fault+0x0/0x3f8) from [<c0085000>] (handle_mm_fault+0x2d8/0xc84)

    [<c0084d28>] (handle_mm_fault+0x0/0xc84) from [<c002ea4c>] (do_page_fault+0xf4/0x1e8)

    [<c002e958>] (do_page_fault+0x0/0x1e8) from [<c0028310>] (do_DataAbort+0x3c/0x9c)

    [<c00282d4>] (do_DataAbort+0x0/0x9c) from [<c0028ec4>] (ret_from_exception+0x0/0x10)

    Exception stack(0xc41a3fb0 to 0xc41a3ff8)

    3fa0:                                     00000000 00000000 00000000 00000000

    3fc0: 0000014c 418aade7 00000002 fffffeb4 40b3d000 00000010 00a18560 bee93c60

    3fe0: 00000000 bee93ad0 00000001 4023f8ec 60000010 ffffffff

     r8:40b3d000 r7:fffffeb4 r6:00000002 r5:418aade7 r4:ffffffff

    we assume that the problem comes when using the edma after soft-reboot.

    regards, Mike

    thanks in advance


  • Min,

    Try to create the test data like this.

    1. First you create the test data file filled with 0xFFFF_FFFF. Basically all bits has to be set. 

    2. Create a test file filled with 0x0000_0000. All bits are cleared.

    Test these two files and see whether any difference in behavior of these two files.

    With this test you can confirm  its a signal integrity issue or not.

    -Renjith

    www.pathpartnertech.com