• State TI Thinks Resolved
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 181 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

TMS570LC4357 EMIF timeout

TMS570LC4357-EP: EMIF not generating extra extended cycle on wait pin trigger.

Deepak C
Prodigy 80 points
Part Number: TMS570LC4357-EP

Tool/software:

All the configurations are same as per what I have read from reference manual. But still not able to extended the strobe access cycle which I got to know while capturing EMIF signals, even after asserting required trigger signal on EMIF_nWait(p3) pin.

As per reference manual, SETUP(2 cycles) and STROBE(3 cycles) is 5 cycles which is greater than 4 cycles.

I have configured in normal mode and started testing.

One strange behaviour what I have observed here is if I give strobe cycle more than 3 and while reading the memory region it is going to data abort. If I disable extended wait cycle, then if strobe cycle is more than 3, I was able to read the data from memory.

So I changed it to select strobe mode and tried with SETUP(2 cycles) and STROBE(3 cycles) , then also it is going to data abort. Then again If I disable extended wait cycle, then if strobe cycle is more than 3, I was able to read the data from memory.

So then for testing purpose I made EMIF_nWait(p3) as GPIOB7 and tried to read pin state. I was able to read pin state of which ever value it is taking. So EMIF_nWait not asserting to configuration polarity is ruled out as I'm able to read it properly for testing purpose.

Any extra configuration do I have to check?

  • 0
    TI__Genius 17171 points

    Hi Deepak,

    The durations for each of these SETUP-STROBE-HOLD should be configurable through the software. What kind of memory are you interfacing with? And are you currently working a custom board or one of our evaluation hardware? You may want to take a look at this application report to ensure you are following all of the general layout guidance http://ti.com/lit/pdf/sprac96

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Prodigy 80 points

    I'm using custom board which is interfacing  with FPGA. I'm running at 50MHz so I'm giving 3 cycles for strobe and setup.

  • 0 in reply to Deepak C
    TI__Genius 17171 points

    Hi Deepak,

    There shouldn't be able any other configuration for further configuring the durations, but are you able to provide scope shots of the memory transactions with data decoding so that we can further verify? Do you have any custom FPGA code running which also may be preventing the EMIF from properly accessing the data with the desired timing

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Prodigy 80 points

    Hello,

    Actually what I'm observing is FPGA is driving wait pin to low. I have verified it by checking the pin. I believe problem is in EMIF side.

  • 0 in reply to Deepak C
    TI__Genius 17171 points

    Hi Deepak,

    If you have already verified that the hardware connection is correct per the application report I sent as well as that the target FPGA is not the cause, then it could be the EMIF configuration. Can you verify that all of the EMIF configuration is correct? Are you using example code or have you written custom software for this? It would be good to ensure that your EMIF is properly configured for the target FPAG specs (which are likely since you are seeing data communication but would be good to double check)

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Prodigy 80 points

    Hello,

    I will get back once after properly verifying  again.

  • 0 in reply to Peter Luong1
    Prodigy 80 points

    One more thing,can you please tell me why I'm going to data abort if I increase the strobe cycle to more than 4 cycles running at 50Mhz in normal mode.

  • 0 in reply to Deepak C
    TI__Genius 17171 points

    Hi Deepak,

    I expect the data abort occurs because target is expecting some specified time for the data write and this is being violated by increasing the strobe cycle. Likely there is CRC being done on the target side and timing is being violated

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Prodigy 80 points

    Hello peter,

    Thanks for your help. Since from FPGA side deassertion was happening with actual storbe cycle configured. That is the reason why wait signal was not extended. Now it is working fine.