Vybrid ProcessorsのトピックQSPI_MCR[ISDnFx]

QSPI_MCR[ISDnFx]

adamszalkowski — Mon, 29 Sep 2014 12:37:41 GMT

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

Re: QSPI_MCR[ISDnFx]

naoumgitnik — Mon, 29 Sep 2014 20:13:46 GMT

Dear Adam,

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

Regards, Naoum Gitnik.

Re: QSPI_MCR[ISDnFx]

adamszalkowski — Tue, 30 Sep 2014 07:20:04 GMT

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

Re: QSPI_MCR[ISDnFx]

naoumgitnik — Tue, 30 Sep 2014 20:49:35 GMT

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.

Re: QSPI_MCR[ISDnFx]

adamszalkowski — Wed, 01 Oct 2014 06:08:27 GMT

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

Re: QSPI_MCR[ISDnFx]

kef2 — Wed, 01 Oct 2014 08:49:35 GMT

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

Re: QSPI_MCR[ISDnFx]

adamszalkowski — Wed, 01 Oct 2014 09:05:50 GMT

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

Re: QSPI_MCR[ISDnFx]

naoumgitnik — Thu, 02 Oct 2014 17:08:36 GMT

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.