TMDSCNCD263P: OSPI Flash Example Questions

Hi Kier,

Kier said:

<Question 1>

I appreciate there are hardware differences between E2 and A of TMDSCNCD263P which mean the OSPI reset pin is toggled by different peripherals in function board_flash_reset(). However, there's still a subtle difference between the pin logic levels for the same OSPI flash IC.

In the first case, the reset is being done via IO expander. In this case we are first pulling it low then high. This is the expected reset sequence according to the flash datasheet.

In the second case, for A revision, the reset is being issued by the OSPI controller. The function OSPI_setResetPinStatus() sets the reset register of the controller. Setting the register would issue the reset. So in this case HIGH does not refer to pulling the line high, but setting reset issue register of the OSPI memory controller. 

Kier said:

<Question 2>

All the TI examples call flashFixUpOspiBoot(). If my application is just reading from OSPI flash do I need to call flashFixUpOspiBoot() at all? Put another way, when do I need to call flashFixUpOspiBoot()?

In the SDK I see that flashFixUpOspiBoot() is used only in SBL examples in examples/drivers/boot folder. This API does a flash reset. Flash reset would be required whenever flash initialization is done. It is done to ensure that the flash is in a known state before initializing. So, you would need to call flash reset before opening the flash driver (or initializing the flash).

Regards,

Aswin

Hi Kier,

Yes they are different methods for giving the reset to OSPI flash.

1. REV E2 uses the Push-Pull IO expander (TCA6424A). Since an Ext. Pull up is done by R120 on P0.0 (GPIO_OSPI_RSTn), the reset line is already in HIGH state.
   Hence from IO_EXP reset logic a "LOW followed by a HIGH" would propagate reset to flash. 
   1. 
2. Later on it was realized that OSPI_RESET0_OUT coming directly from the controller is left unused and hence the OSPI Reset Architecture was modified to use OSPI_RESET0_OUT as input to AND gate(so that we can use the P0.0 of IO.EXP for any other general application)
   1. In case of using OSPI_RESET0_OUT from controller below is the truth table:

      1. RESET_CFG_FLD	RESET_CFG_FLD	OSPI RESET Line Logic Level
         1	0	HIGH
         1	1	LOW
         0	1	LOW
         0	0	LOW

• Kier said:

  Am I right to think that toggling the GPIO pin (J1) signal OSPI0_RESET_OUT0 is equivalent to using OSPI_setResetPinStatus()

Yes, technically it is the same. RESET line to flash should have a HIGH->LOW->HIGH transistion. Since OSPI IP has a dedicated reset pin, REV A utilizes that feature.

NOTE: While designing a custom board use WARM_RSTn instead of PORz along with OSPI_RESET_OUT as shown below

Thanks & Regards,
Rijohn