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.

AM625: Enable pulls on OSPI/QSPI signals in ROM bootloader

Part Number: AM625

According to the FQA, recommend to add external pulls on O/QSPI signal for Q/OSPI bootmode. 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1307344/faq-am625-am623-am620-q1-am62l-am62ax-am62d-q1-am62px-design-recommendations-commonly-observed-errors-during-custom-board-hardware-design-ospi-qspi-memory-interface

Suggest to enable OSPI interrupt pull up/down in ROM code to eliminate external pulls in roadmap device, it can simplify schematic and save PCB size.

image.png

  • Hello Tony,

    Thank you for the query.

    Most of the IOs depending the processor family support mux mode (pin can be configured for one of the multiple functions defined)

    SOC IO buffers are off during reset and after reset.

    The enabling of internal pulls for peripherals depend on the memory interface implementation and the standards.

    Example: eMMC JEDEC standard required external pull for D0 and CMD signals.

    For SD card interface an external pullup for the data and CMD signals are recommended.

    As i understand the OSPI interface does not have requirements. The external pullups are recommended to hold the memory interface signals from floating.

    The OSPI interface is not limited to using for boot. The OSPI IOs when not configured for OSPI can be used for alternate functions.

    Hence external pullups are recommended when the IOs are configured for OSPI functionality. 

    Regards,

    Sreenivasa

  • As mentioned by Sreenivasa, we do not turn on internal pulls of pins that support multiplexed signal functions because we do not know what is going to be connected to these pins. Turning on internal pulls by default could introduce a mid-supply condition on signals if the attached device has an internal pull turned on by default that is in contention with the AM62x internal pull.

    You may ask, why not have the ROM code turn on the internal pulls once it detects OSPI boot mode. The answer to this question is, because the inputs of the attached device would be left floating until the ROM code detects OSPI boot mode and configures the internal pulls. 

    Creating a condition where signals are held in a mid-supply state or allowing signals to float is a bad design practice, so we recommend external pulls on the signals to ensure the attached device inputs are held in a valid logic state as soon as power is applied.

    Regards,
    Paul

  • The answer to this question is, because the inputs of the attached device would be left floating until the ROM code detects OSPI boot mode and configures the internal pulls. 

    Yes, this is my question. Will the floating introduce problem? Did not see such requirement is data sheet: Table 6-74. Connectivity Requirements

    For example, when OSPI interface is not used, there isn't requirement to pull OSPI signals with resistors.

    allowing signals to float is a bad design practice, so we recommend external pulls on the signals to ensure the attached device inputs are held in a valid logic state as soon as power is applied.

    Should pulls all signals externally no matter used or not on AM62x beside follow datasheet table 6-74. Connectivity Requirements?

  • You should never allow a digital signal to float.

    Some device input buffers may tolerate floating or mid-supply voltage for long periods of time, but in general it is not a good design practice to allow this to happen because the input buffer will have its p-channel and n-channel transistors partially turned on when its input is at mid-supply. This causes shoot-through current to flow from VDD to VSS through the input buffer. Too much time spent in this condition can stress the circuits in the input buffer, which can result in electromigration issues or premature aging of the transistors.

    You should never allow a mid-supply voltage on any AM62x input buffer when its RXACTIVE bit in the respective PADCONFIG register is enabled. It is okay to apply a mid-supply voltage to a AM62x input when the RXACTIVE bit is disabled. The second paragraph of the note following the Connectivity Requirements table addresses this concern by saying "Any IO with its input buffer (RX) turned off is allowed to float without damaging the device. However, any IO with its input buffer (RX) turned on shall never be allowed to float to any potential between VILSS and VIHSS. The input buffer can enter a high-current state which could damage the IO cell if allowed to float between these levels."

    This concern is also addressed by the minimum input slew rate parameter in each of the Electrical Characteristics tables. The signal should never spend more than 1000ns in the voltage transition region between VILSS and VIHSS. The 1000ns limit applies for signal toggle frequency up to 100kHz. The min slew rate decreases as a function of toggle frequency once the signal toggle rate increases above 100kHz.

    In the case where no OSPI device is connected, you can leave the pins unconnected as long as you ensure software never enables the RXACTIVE bit and you do not connect any PCB signal trace to the pins.

    Regards,
    Paul