• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 290 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC4357: EMIF memory browser inconsistent with written data.

Josh Blohm
Prodigy 70 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hello, I'm using the Hercules HDK and I've successfully gotten the example_emif_sdram.c example working to demonstrate successful configuration of the emif peripheral. I have removed the blinky code and tailored the main.c file to now write 0xA5A5 to the first 100 16-bit words in the SDRAM memory region. I have modified the example HALCoGen configuration by disabling cache and making the SDRAM Memory region (RW).

After writing 0xA5A5 I see 0xE5A5 in the memory browser indicating that D15-D14 are not as intended.

in main:

emif_SDRAMInit();

const uint16_t *buffer_loc = 0x80000000;

uint32_t i;
for( i=0; i<100; i++ )
{
    *(uint16_t *)&buffer_loc[i] = 0x5000;
}

I have duplicated this similar behavior on D15-D14 for writing other data values: 0x5000 sets 0xD000, 0x7000 sets 0xF000, and 0x9000 sets 0xD000.  

Am I missing a fundamental understanding? Why am I seeing this behavior for D15-D14?

  • 0
    TI__Guru**** 192716 points

    Can you write 0x5A5A the SDRAM in the example's main()?

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Thanks for your reply. We ran your suggested test of writing 0x5A5A which set 0xDA5A. We also tried more values to provide more context for characterizing the problem.

    Writing 0x25A5 sets 0x25A5.

    Writing 0x65A5 sets 0xE5A5.

    Writing 0xA5A5 sets 0xE5A5.

    Writing 0xE5A5 sets 0xE5A5.

  • 0 in reply to Josh Blohm
    TI__Guru 63005 points

    Hi Josh,

    Can you make sure that there are no physical shorts between D15 and D14?

    My understanding from your data is below

    If either of the D15 or D14 becomes one then both are becoming 1.

    Is it possible for you to tap D15 and D14 with either CRO or logic analyzer for different inputs as shown above?

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 70 points

    Jagadish,

    The SDRAM (U8) on the HDK is a ball grid array. The only testable points are on RN10 or J10. The best I am able to do in my current setup is probe these pins with a multimeter to check for continuity. The following are the results for open or closed connection:

    RN10-16 and RN10-15 = open

    RN10-1 and RN10-16 = closed

    RN10-2 and RN10-15 = closed

    J10-55 and J10-56 = open

  • 0 in reply to Josh Blohm
    TI__Guru**** 192716 points

    Hi Josh,

    Can you try my test project? There is no problem for me to write data to SDRAM.

  • 0 in reply to QJ Wang
    Prodigy 70 points

    QJ, 

    Thanks for the test project. Here are my results:

    It seems I have a hardware issue. It's worth noting. Our project is constrained to CCS v9.3.0.00012. The project you sent me had problems building using this version. It uses compiler option TI v17.9.0.STS[TI v18.12.4.LTS]. Our project and these results use TI v18.12.4.LTS.

    What could be the cause of .blinky mismatching? Is this due to the compiler mismatch?

  • +1 in reply to Josh Blohm
    TI__Guru**** 192716 points

    I think that the pin R7 (EMIF_DATA[14]) and R8 (EMIF_DATA[15]) are shorted on your PCB board.