QSPI_MCR[ISDnFx]

[adamszalkowski]

The Vybrid manual claims that during QuadSPI commands IOFx[3:2] are "driven all the time, values taken from QSPI_MCR[ISDnFx]".

I can not find any information on these two bits in the documentation of the QSPIx_MCR register. Where can I find this information.

The other question is how to drive these two pins to HIGH during QuadSPI boot? Are there any undocumented eFuses for this purpose?

Currently, these pins are low during boot and thus the HOLD# pin is active, which leads to no data being transferred.

Best regards,

Adam

[naoumgitnik]

Dear Adam,

Please, take a look at the Re: QSPI I/03 Diven Low during all Single bit accesses thread.

Regards, Naoum Gitnik.

[adamszalkowski]

So, apparently this means that IOF[3:2] pads are not driven in 1- and 2-bit modes.

I wonder how this is solved on the TWR-VF65GS10. There, IOF[3] is driven high.

I doubt this is done by the PI3B3257QE. This part seems to only multiplex between SPI or QSPI.

I can not spot any pull-ups either.

Regards,

Adam

[naoumgitnik]

Hello Adam,

It might be high due to the Vybrid built-in pull-up being active... If you need all these details, it makes sense for your team to look into the Vybrid tower module's SW code; it is linked to on the Freescale TWR-VF65GS10 web page as well as its location mentioned in the Re: Re: Re: Can I get working sources of U-BOOT 2013.07, nand? and Re: Re: Using PLL5 for RMII-Clock threads.

Regards, Naoum Gitnik.

[adamszalkowski]

Hello Naoum,

we are talking here about the state during boot i.e. the boot ROM code. Do you have sources for that?

Regards, Adam

[kef2]

Hi Adam,

Spansion QSPI memory used in Vybrid Tower card, has nonvolatile QUAD bit. Once you program it to 1, /HOLD and /WP pin functions are not used any more. It only matters how do you do initial Spansion memory programming. And for initial programming you can either drive /HOLD and /WP to required levels or set Vybrid pads to pull pads to the right direction.

Edward

[adamszalkowski]

Edward, thanks for the workaround.

Anyway, still curious why QSPI0_A_D3 is driven high on the tower board during boot. Undocumented eFuses?

Regards,

Adam

[naoumgitnik]

Adam,

I guess it is caused by the bootROM code, and since in the mode of interest this bit is ignored by the memory chip, nobody worried about its configuration.

Sincerely, Naoum Gitnik.