i.MX ProcessorsのトピックRe: ECSPI 1, CS 1 sf probe issue?

ECSPI 1, CS 1 sf probe issue?

repoman — Thu, 19 Jun 2014 19:15:48 GMT

All,

I have a prototype board that has an i.MX6 Quad on it. Similar to the sabrelite, I have implemented an SPI EEPROM (SST25V chipset) on the ECSPI 1 chip select 1. I actually have two EEPROMs at both Chip select 0 and Chip Select 1 location.

I believe I am having a U boot issue but am uncertain as to the configuration mode that I should be in. When I run "sf probe" in u boot, The output message is:

"SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB"

However, if I try to do an sf probe with any arguments U boot returns the message:

SF: Unsupported flash IDs: manuf 00, jedec 0000, ext_jedec 0000

Failed to initialize SPI flash at 0:1"

I can then run sf probe again and it says the first message where the SST25V is detected.

As this is a prototype Revision 0 and I have had it for all of 7 days, I thought I was having a hardware issue. So I have attached my oscilloscope to the SST25V SPI pins. In doing so I have found something odd and I am hoping someone has seen this and can chime in and say "no, you need to configure u boot to do..." (because I have not quite figured it out yet).

When the "sf probe" command is run by itself, I see all of the SPI signals sending/receiving data, chipselect and the clock. As soon as I add an argument, I have no activity on the SPI channel. I have tried doing "sf probe 0:1 1000000 0" which should probe ECSPI channel 1, chip select 1 at 1MHz in Mode 0. However, I get nothing and have tried many combinations of this and not seen a single activity.

Has anyone seen and/or over come this? I am certain it is a U boot configuration as the sf probe command does work just fine.

Thank you for the time,
John

Re: ECSPI 1, CS 1 sf probe issue?

jimmychan — Tue, 01 Jul 2014 07:37:35 GMT

Please double check all the IOMUX and PAD setting for the SPI pins. e.g. In the mx6_pins.h, please check the pad setting of the SPI pins that you are using is MUX_PAD_CTRL(MX6Q_ECSPI_PAD_CTRL).

Re: ECSPI 1, CS 1 sf probe issue?

repoman — Tue, 01 Jul 2014 13:40:46 GMT

Jimmychan,

Thanks. I double checked the pads and these were not directly the issue. Basically, if you want to probe something other than the default sf probe (which worked fine). Then the flag value for chip select is not a logical value (say 0.. 3) but a formulaic value based on the GPIO pin and a few other items. This information can be found by searching where the #define CONFIG_SF_DEFAULT_CS (0|IMX_GPIO_NR(3,19)<<8) is set. I looked up the Macro for IMX_GPIO_NR and the definition is a formula:

[Found in arch/arm/include/asm/imx-common/gpio.h]

#define IMX_GPIO_NR(port,index) ( ((( port ) - 1)*32) + ((index)&31) )

By finding this, I could then access any chip select as long as I knew the exact GPIO port and index (which I do). My specific board has two on board EEPROMs which will eventually enable the ability to do other kinds of security checks for tampering. However, I wanted to know that I could access both by sending something like sf probe <SPI bus #>:<CS #>, etc. However, the <CS #> is not actually logical but derived by the IMX_GPIO_NR() value and then rolled left 8 positions.

R,
John

Re: ECSPI 1, CS 1 sf probe issue?

jimmychan — Wed, 02 Jul 2014 05:24:25 GMT

This may useful for you:

https://community.freescale.com/message/394136#394136

https://community.freescale.com/message/405462#405462