• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 576 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EMIF causing high current consumption

Alan Day
Intellectual 920 points
Other Parts Discussed in Thread: SN74LVCH16245A, TMS570LS3137

Hi,


I initially though this problem was due to the SN74LVCH16245A, as discussed in this thread, however after further investigation the fault seems to be coming from the TMS570LS3137's EMIF, hence posting the problem here.

In summary:

-EMIF data pins connected to SN74LVCH16245A.

-Power planes (3v3 and GND) identical to TMS570

-No resistors on data lines

-EMIF pins enabled via pinmux and systemREG1->GPREG1 |= (1 << 31U);

-Write mode - Output follows input, low current draw (+10mA)

-Read mode - Output does not follow input, increased current consumption (+300mA)

Blue - from NOR Flash

Red - Reproduced by SN74LVCH16245A to TMS570

-SN74LVCH16245A unable to keep signal high due to TMS570

-SN74LVCH16245A tested with other peripherals set as GPIOs, increase current draw not seen.

-SN74LVC16245A tested with TMS570, even higher current draw when in read mode (+400mA)

Red - Signal from NOR flash

Blue - Output to TMS570, repeated drops in signal, TMS570 reads as 0 instead of 1.

Questions:

What mode is the pin operating in when the EMIF is set to read?

Why is it sourcing such a large current from the SN74LVCH16245A?

Any suggestions as to how to resolve this?

Cheers,

Alan

  • 0
    TI__Guru 68920 points

    Alan,

    My initial response was going to be to ask you to see the schematic, and to ask how you're controlling the 16245.  But then I saw the link to your other post and saw a schematic there.  Assuming that we're talking about the 16245 on sheet 5 of the PDF,  I think I can guess at the problem.

    It looks like you are trying to control the direction of the bus transceiver with a GIO pin instead of through the EMIF's control logic outputs.    

    In that case, you need to know that the EMIF has bus parking which means it will drive a known value on the data lines when it is not busy making a transaction.  

     

    So you can't just turn the direction of the 16245 so that it drives the TMS570 and then try to do only EMIF reads, because in the downtime the TMS570 EMIF will be parked and driving out against the 16245.

    My first question would by why you're not using the EMIF control lines like WE\, OE\, CS\ etc to control the 16245.  Especially if you had the CS\ of the async ports controlling the enable of your 16245 I think you'd alleviate this problem.

    If you have issues making a board change you could try using the Self Refresh command on the SDRAM interface.  From what I see in the TRM this might disable parking, and it doesn't look like you have an SDRAM.  But I'd consider this a workaround, because it would be easy through a software bug to cause the high current situation again.  It would be best to have a hardware fix that logically never turns on the 16245 when the async memory is deselected.

    EDIT:  This is a bit ironic, but I should point out that the bus parking is an important feature.  It keeps your EMIF from otherwise having many floating inputs (and thus high current consumption - potentially) when there is no activity on the bus.   I didn't see the 'reason' why we have this in our TRM so I thought I should explain.

  • 0 in reply to Anthony F. Seely
    Intellectual 920 points

    Hi Anthony,


    Thanks for sorting this out as well, I forgot that the EMIF had bus parking, to initially resolve this I just inserted code to turn the 16245 on and off each side of any reads, this worked quite well, reducing the larger current draws.


    Tomorrow I will wire the CS to the 16245's EN pin, however I'm unable to disconnect the nHET pin it is also connected to so I will instead change this pin to an input GPIO with no pull up or down and have no code associated to it after the initial setup.

    Kind regards,

    Alan