• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 122 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.

TMS320F28386D: EMIF block issue

HS FAE Germany
Mastermind 33230 points

Part Number: TMS320F28386D

Hello,
customers sees an issue with EMIF2 and external ADC connected to it.

  • The ADC is clocked via a GPIO and produces a new sample with each clock pulse. They read the value via the EMIF2 data lines.
  • The EMIF2 is configured in asynchronous mode, but only the data lines are used.
  • The ADC is the only device on the EMIF2 bus and during a sample series constantly drives the bus (output enabled).
  • The EMIF2 normally “parks the databus” after an asynchronous read.
    • They discovered that by seeing the databus having strange behaviour during the sampling process.
    • They were able to fix it by setting the Self-refresh bit in the SDRAM settings of the EMIF and doing a read cycle.
    • However, somehow the unwanted driving of the datalines by the EMIF has reappeared now, despite the described fix.

Question: is there a way, as described or otherwise, to make sure that the EMIF does not “park the bus”?

Regards, Holger

  • 0
    TI__Mastermind 25031 points

    Hi,

    I am currently returning from business travel and catching up on forum questions. I will get back to you shortly

    Regards,

    Peter

  • 0 in reply to Peter Luong
    TI__Mastermind 33230 points

    Hi Peter,
    can you send me a response?

    Regards, Holger

  • 0 in reply to HS FAE Germany
    TI__Mastermind 25031 points

    Hi Holger,

    Referring to the TRM (Section 12.2.7): The EMIF always drives the data bus to the previous write data value when the EMIF is idle. This is called data bus parking. Only when the EMIF issues a read command does it stop driving the data bus. After it latches the last read data, it immediately parks the data bus again.

    This is by design and cannot be disabled through a dedicated register bit. There is no configuration option to permanently disable bus parking.

    Setting the SR bit puts the EMIF in self-refresh mode, which has a special exception that after an asynchronous read while in self-refresh state, the EMIF tri-states the data bus instead of re-parking it. The TRM mentions that the EMIF does not park the data bus following a read to asynchronous memory while in the self-refresh state. Instead, the EMIF tri-states the data bus. However, the EMIF exits self-refresh if either of these events occur: The SR bit is cleared to 0 or an SDRAM access is requested. So if anything in the application code triggers an SDRAM access, the EMIF exits SR and bus parking can occur. You can try to verify this by monitoring the SR EMIF bit

    Regards,

    Peter

  • +1 in reply to Peter Luong
    TI__Mastermind 33230 points

    Hi Peter,
    thank you for the confirmation of our interpretation of the TRM regarding the EMIF ‘bus parking’. With this knowledge and a little more experimenting, customer could resolve this issue.  

    • Since the EMIF2 clock (connected to the 40 MHz ADC sample clock input) could not be configured below 100 MHz, they had decided for a workaround to clock via software, and keep the ADC OutputEnable on during a sampling series, in the expectation to let the ADC drive the databus constantly.
    • The ‘bus parking’ got in the way, but with the trick mentioned below, parking can be replaced with ‘tri-state’ on the EMIF side.
    • However, with the ADC driving a 3.3V level on a dataline, they could measure that, with the corresponding GPIO as input, the voltage on the line drops to 1.66V when we switch the Open-Drain feature of the GPIO on.
    • Since that is the level they see as disturbance during sampling and assuming that the tri-state mode has a similar impedance, they have concluded that the ADC cannot handle the tri-state mode of the EMIF, like the bus parking.
    • Back at the drawing board, they made a hardware workaround by connecting the ADC clock to the OutputEnable signal (driven by EMIF_OEN) and I replaced the software-control of the clock and OutputEnable with a regular read cycle on the EMIF. Problem solved.

    Regards, Holger