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.

Repeatable SDRAM write failure with TMS570LS3137 HDK

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

I recently uncovered a repeatable error writing to SDRAM on my TMS570LS3137-based design. I have been able to reproduce the problem on the TMS570LS3137 HDK, so it appears to be more than just an isolated hardware issue.

The problem can be reproduced with the IAR compiler performing a memcpy of 134 bytes to SDRAM. This yields eight 16-byte block writes (STM instruction), followed by one word write (STR instruction), followed by one half-word write (STRH instruction). Under these circumstances the one word write fails to alter the SDRAM. I have only seen the error when the memcpy size yields this pattern of accesses (n*16 + 4 + 2 where n >= 8). Also the error does not occur if I single-step through the code with the debugger.

I've confirmed the Halcogen configuration: 80MHz EMIF clock, all other timings meet the IS42S16400  specs.

Here is code that reproduces the problem for me:

void TestSDRAM(void)
{
    uint8_t src[512];
    memset(src, 0xFF, 512);  // Internal RAM source initialized to FFs

    uint8_t * const dest = (uint8_t *)0x80000000;
    memset(dest, 0, 512);  // External SDRAM destination initialized to 0s

    // Copy src to dest fails when length = n * 16 + 4 + 2
    uint32_t length = 134u;
    memcpy(dest, src, length);

    // Verify copy
    for (int i = 0; i < length; i++)
    {
        assert(dest[i] == src[i]);
    }
}

I've tried increasing the EMIF timings without success. Any ideas?

  • Did you see to Errata document SPNZ195F chapter DEVICE#B064 ?

    Your behavior looks like this. Problem is optimized memcpy, it use STM intruction and it fail on this bug.
    If I know HDK  board from TI contain silicon revision C with this bug.
    You can updrade silicon to revision D or use some workaround (TI compiler have it, GCC can disable builtin memcpy + don't use struct assigment, but I don't knoew how to do it on IAR)

  • Thank you! I have no doubt that my issue is in fact explained by erratum DEVICE#B06.

    Now I just have to decide on the best work around.