• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 636 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.

TDA4VM: OSPI0’s reset_out pin

Guanghai Cai
Prodigy 40 points

Part Number: TDA4VM

In datasheet, pin A23/E22 are defined as MCU_OSPI0_RESET_OUT pins in OSPI0 bus. 

Is it possible to implement the MCU_OSPI0_RESET_OUT function via a regular GPIO, while free A23/E22 for their secondary functions, e.g. MCU_OSPI1_CSn1 (E22), MCU_OSPI1_LBCLKO (A23)..

what's the special of these embedded OSPI reset pins? What's the concerns/risk/tradeoff (software effort) if the OSPI reset function is implemented by a regular GPIO?

The reason I am asking is in our design, OSPI1 (we just use as a standard SPI) required two CS signals, but one supported pin E22 has been used as MCU_OSPI0_RESET_OUT1 by OSPI0. To minimize the pinout shuffle to relocate this SPI, we would like to see the feasibility of above proposal.

Thanks!

  • 0
    TI__Genius 17186 points

    The RESET_OUT signal is asserted only when SPI interface is idle and corresponding chip-select is de-asserted.  So using GPIO may be possible if software can guarantee these two conditions.

    It may be tricky for software since the idle indicator (OSPI_CONFIG_REG[31].IDLE_FLD) is a snapshot in time and could result in race conditions if OSPI is actively used (for example software could sample idle indicator and next cycle a new request comes and OSPI is no longer idle). 

    So recommended method is to use the RESET_OUT from OSPI.  If software can guarantee a controlled environment where there are no active requests to OSPI, then it can use GPIO method.