2011-06-27 07:07:57     SPI bus contention, SDCARD detect failure- 2010R1

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-06-27 07:07:57     SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 101710   

 

hi,

 

We have mulitiple SPI SLAVE devices on our platform (TLL6527M using ADSP-BF527 and uclinux 2010R1-RC5 with matching toolchain). We're facing problems detecting the SDCARD (connected to SPI bus at SS)

 

See attached platform file for mapped resources. Please note that while testing SDCARD, following spi device drivers were selected during uClinux build:

 

1. SPI NOR FLASH (connected to SSEL1) - as kernel built in

 

2. bfin-lq035q1-fb (mapped to PH9 as Slave select) -as loadable module

 

3. spidev (mapped to PH9/nSPISEL5) as loadable module

 

4. sdcard drivers (mmc_core, mmc_block & mmc_spi mapped to PH12 as slave select) as loadable modules

 

Also since the mmc_spi driver has bus exclisivity issue, I compiled the spi driver while selecting option "SPI Bus lock" under "SPI controller driver for ADI Blackfin" as suggested in this thread:

 

https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=45602&action=ForumBrowse&forum_id=39

 

 

 

Problem is that while mounting the sdcard we see following error messages:

 

mmc_spi spi0.52: adding an msg in transfer()

mmc_spi spi0.52: setup spi chip mmc_spi, width is 8, dma is 0

mmc_spi spi0.52: ctl_reg is 0x1000, flag_reg is 0x0

mmc_spi spi0.52: chip select number is 52

mmc_spi spi0.52: setup mode 0, 8 bits/w, 400000 Hz max --> 0

mmc0: req done (CMD52): 0: 00000000 00000000 00000000 00000000

mmc0: starting CMD52 arg 80000c08 flags 00000195

mmc_spi spi0.52:   mmc_spi: CMD52, resp R2/R5

mmc_spi spi0.52: adding an msg in transfer() 

mmc_spi spi0.52: setup spi chip mmc_spi, width is 8, dma is 0 mmc_spi spi0.52: ctl_reg is 0x1000, flag_reg is 0x0

mmc_spi spi0.52: chip select number is 52

mmc_spi spi0.52: setup mode 0, 8 bits/w, 400000 Hz max --> 0

mmc0: req done (CMD52): 0: 00000000 00000000 00000000 00000000

mmc0: starting CMD0 arg 00000000 flags 000000c0

mmc_spi spi0.52:   mmc_spi: CMD0, resp R1

mmc_spi spi0.52: adding an msg in transfer() 

mmc_spi spi0.52: setup spi chip mmc_spi, width is 8, dma is 0

mmc_spi spi0.52: ctl_reg is 0x1000, flag_reg is 0x0

mmc_spi spi0.52: chip select number is 52

mmc_spi spi0.52: setup mode 0, 8 bits/w, 400000 Hz max --> 0

mmc0: req done (CMD0): 0: 00000000 00000000 00000000 00000000

mmc0: starting CMD8 arg 000001aa flags 000002f5 mmc_spi spi0.52:

mmc_spi: CMD8, resp R3/R4/R7 mmc_spi spi0.52: adding an msg in transfer()

mmc_spi spi0.52: setup spi chip mmc_spi, width is 8, dma is 0

mmc_spi spi0.52: ctl_reg is 0x1000, flag_reg is 0x0

mmc_spi spi0.52: chip select number is 52

mmc_spi spi0.52: setup mode 0, 8 bits/w, 400000 Hz max --> 0

mmc0: req done (CMD8): 0: 00000000 00000000 00000000 00000000

mmc0: starting CMD5 arg 00000000 flags 000002e1

mmc_spi spi0.52:   mmc_spi: CMD5, resp R3/R4/R7

mmc_spi spi0.52: adding an msg in transfer() 

mmc_spi spi0.52: setup spi chip mmc_spi, width is 8, dma is 0 mmc_spi spi0.52: ctl_reg is 0x1000, flag_reg is 0x0

mmc_spi spi0.52: chip select number is 52

mmc_spi spi0.52: setup mode 0, 8 bits/w, 400000 Hz max --> 0

mmc0: req done (CMD5): 0: 00000000 00000000 00000000 00000000

mmc0: host doesn't support card's voltages mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0

mmc_spi spi0.52: mmc_spi: power off (0)

mmc0: error -22 whilst initialising SDIO card

mmc0: clock 0Hz busmode 2 powermode 0 cs 1 Vdd 0 width 0 timing 0

--------------------------------------------------------------------------------------------

 

-> This only happens when a spi slave is connected to PH9/nSPISEL5, otherwise sdcard mounting goes through fine. Since the spidev module is still not loaded while mouting sdcard, there should be no activity on PH9/nSSEL5. So we checked out the activity on both SDCARD slave select and PH9/nSPISEL5 while mounting sdcard.

 

-> Attached document contains waveforms showing PH9/nSPISEL5 also being toggled alongwith PH12 asseted while SDCARD mounting. This violates SPI standard and seems to be leading to SPI bus contention.

 

Why would PH9 be toggled during sdcard mounting since only PH12 is mapped as SPI CS for sdcard? How can we avoid that?

 

Thanks & regards

 

Ashish

 

 

 

SPI Contention.doc

tll6527m.c

QuoteReplyEditDelete

 

 

2011-06-28 16:06:12     Update: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 101806   

 

Hi,

 

An update, I repeated the bove experiment to test the impact of sdcard driver load on the other slave select lines.

 

->Attached is updated document, it contains waveforms showing nSPISEL1 (being used as a chip select for on board SPI NOR FLASH) also being toggled alongwith PH12 while SDCARD mounting. This violates SPI standard and seems to be leading to SPI bus contention.

 

This happens while firing "modprobe mmc_spi".

 

Regards

 

Ashish Gupta

 

SPI Contention_20110629.doc

QuoteReplyEditDelete

 

 

2011-06-28 16:09:37     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 101807   

 

One correction, the SHARP display SPI CS is connected to PH10 hence, bfin-lq035q1-fb driver is mapped to PH10 gpio for SPI CS.

 

1. SPI NOR FLASH (connected to SSEL1) - as kernel built in

 

2. bfin-lq035q1-fb (mapped to PH10 as Slave select) -as loadable module

 

3. spidev (mapped to PH9/nSPISEL5) as loadable module

 

4. sdcard drivers (mmc_core, mmc_block & mmc_spi mapped to PH12 as slave select) as loadable modules

QuoteReplyEditDelete

 

 

2011-06-30 02:46:01     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 101881   

 

What kind of spi device did you connect to the PH9/SPISSEL5? Did you remove this spi device on PH9/SPISSEL5 when detecting the attached waveform? If not please remove the device and detect the PH9/SPISSEL5 wave form again.

QuoteReplyEditDelete

 

 

2011-06-30 09:04:02     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 101929   

 

Hi Aaron

 

PH9/nSPISEL_3V3 is connected to the enable pin of U60 which is a buffer on the SPI MISO line. The buffer enable is active low, so U60 will drive the MISO line only if PH9/nSPISEL5_3V3 is asserted low, input side of U60 buffer is connected to our GPIO connctor for external device interfacing. Assuming that the linux drivers comply with SPI standard and don’t toggle the PH9/nSPISEL5_3V3 until the device driver mapped to it is trying to read/write, there should be no contention on the SPI BUS. We intend to map spidev to PH9/nSPISEL5. Please see attached document last page, I've added a HW block diagram for your reference.

 

 

 

As far as the waveforms are concerned, since the PH9/nSPISEL5 is going to the enable input pin of U60, it doesn’t matter if the buffer is present or not. The waveforms are identical for both cases with/without the U60 buffer. But obviously if we remove the buffer, then the SDCARD driver is able to detect and instantiate the card and we are able to read/write to it without any issues. That's because no device drives SPI MISO (other than SDCARD) when PH9/nSPISEL5 is asserted low druing SDCARD driver load.

 

Regards,

 

Ashish

 

SPI Contention_20110630.doc

QuoteReplyEditDelete

 

 

2011-06-30 10:47:15     Re: SPI bus contention, SDCARD detect failure- 2010R1

Mike Frysinger (UNITED STATES)

Message: 101933   

 

please detail the exact clients you have hooked up via SPISEL# or using a GPIO CS, and the spi modes each are operating in.  or just post your boards file which has all of these details in them.

QuoteReplyEditDelete

 

 

2011-06-30 18:29:34     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 101943   

 

Hi Mike,

 

I had already attached my board platform file "tll6527m.c" above with the first post. Here is the spi board info extracted as below:

 

static struct spi_board_info bfin_spi_board_info[] __initdata = {

#if defined(CONFIG_MTD_M25P80) \

    || defined(CONFIG_MTD_M25P80_MODULE)

 

/*

* TLL6527Mv1-1 has an SPI Chip Select line mapped to the GPIO connector.

* User can add external devices to that line. It is PH9/nSPISEL5_3V3.

* Its native bfin SPI slave select #5.

*/

    {

        /* the modalias must be the same as spi device driver name */

        .modalias = "m25p80", /* Name of spi_driver for this device */

        .max_speed_hz = 20000000,

                /* max spi clock (SCK) speed in HZ */

        .bus_num = 0, /* Framework bus number */

        .chip_select = 1,

        .platform_data = &bfin_spi_flash_data,

        .controller_data = &spi_flash_chip_info,

        .mode = SPI_MODE_3,

    },

#endif

 

#if defined(CONFIG_MMC_SPI) || defined(CONFIG_MMC_SPI_MODULE)

    {

        .modalias = "mmc_spi",

/*

* TLL6527M V1.0 does not support SD Card at SPI Clock > 10 MHz due to

* SPI buffer limitations

*/

        .max_speed_hz = 20000000,

                    /* max spi clock (SCK) speed in HZ */

        .bus_num = 0,

        .chip_select = GPIO_PH12 + MAX_CTRL_CS,

        .controller_data = &mmc_spi_chip_info,

        .mode = SPI_MODE_0,

    },

#endif

#if defined(CONFIG_SPI_SPIDEV) || defined(CONFIG_SPI_SPIDEV_MODULE)

    {

        .modalias = "spidev",

        .max_speed_hz = 15000000,

        /* TLL6527Mv1-0 supports max spi clock (SCK) speed = 10 MHz */

        .bus_num = 0,

        .chip_select = 5,

        .mode = SPI_CPHA | SPI_CPOL,

        .controller_data = &spidev_chip_info,

    },

#endif

#if defined(CONFIG_FB_BFIN_LQ035Q1) || defined(CONFIG_FB_BFIN_LQ035Q1_MODULE)

    {

        .modalias = "bfin-lq035q1-spi",

        .max_speed_hz = 15000000,

        .bus_num = 0,

        /* TLL6527Mv1-1 has PH10 mapped to LCD CS */

        .chip_select = GPIO_PH10 + MAX_CTRL_CS,

        .controller_data = &lq035q1_spi_chip_info,

        .mode = SPI_CPHA | SPI_CPOL,

    },

#endif

 

};

 

Note that while compiling the kernel, only the following drivers were enabled in respective modes:

 

1. CONFIG_MTD_M25P80: SPI NOR FLASH (connected to SSEL1) - as kernel built in

 

2. CONFIG_FB_BFIN_LQ035Q1_MODULE: bfin-lq035q1-fb (mapped to PH10 as Slave select) -as loadable module

 

3. CONFIG_SPI_SPIDEV_MODULE: spidev (mapped to PH9/nSPISEL5) as loadable module

 

4. CONFIG_MMC_SPI_MODULE: sdcard drivers (mmc_core, mmc_block & mmc_spi mapped to PH12 as slave select) as loadable modules

 

Also while performing the above experiments, the LCD module was not connected so there were only two spi slaves, the nor flash and mmc card devices on the spi bus alongwith the U60 buffer who's enable line is connected to PH9/nSPISEL5. See HW block block diagram in the document attached with previous post "SPI_Contention_20110630.doc"

 

Let me know if you need any more info.

 

Regards

 

Ashish

QuoteReplyEditDelete

 

 

2011-06-30 18:37:17     Re: SPI bus contention, SDCARD detect failure- 2010R1

Mike Frysinger (UNITED STATES)

Message: 101944   

 

sorry, i missed the attached file in the first post.  i saw you enumerate the clients, but not to the level of detail we need to reproduce things.  the boards file should be sufficient though.

QuoteReplyEditDelete

 

 

2011-07-01 02:24:37     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 101949   

 

Thanks for you information, from your description,can we conclude that you have also observed the PH9 being toggled when SD is enbaled even if the buffer is removed(yes we understand theoratically the as it's connected to input of another device so it should not matter, actually I guess the level shifter matters more than the U60 from your schematic as it's directly connected to PH9)

 

As from the code we can not see how the PH9 is handled by accident or bug, could you remove the R36 and test again to double confirm that PH9 is really toggled by software in the Blackfin.

 

If still toggled, together with your description, we may conclude that the PH9 is handled by SD driver or something related with it by accident and will go on to check.

QuoteReplyEditDelete

 

 

2011-07-01 02:36:30     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 101950   

 

Sorry, missed something, after removing the R36, you still need to pull the PH9 PIN up to the 1V8 before the test.

QuoteReplyEditDelete

 

 

2011-07-01 04:18:46     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 101973   

 

Hi Aaron,

 

Understood. Actually its a bit tricky to remove the R36 resistor pack and then add the pullup R because we have a very dense board. Nonetheless, I will give it a try and get back with results.

 

Regards,

 

Ashish

QuoteReplyEditDelete

 

 

2011-07-01 05:46:05     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 101977   

 

Thanks, from your board file the MMC is using gpio as the chipselect, so the driver code only use gpio_set_value to toggle the PIN for MMC, can't figure out why the PH9 is also toggled as decribed in your doc file. Have you checked if there is some other driver that handling the PH9? If there is such a driver then it make sense, once some real dev is connected to PH9, it response to the active chipselect and toggle MISO/MOSI randomly to interfere with the MMC mounting.

QuoteReplyEditDelete

 

 

2011-07-02 10:19:01     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 102046   

 

Hi Aaron,

 

I've repeated the experiment after removing the level shifting buffer U54 - ADG3301 to confirm PH9/nSPISSEL5 line toggle by SDCARD driver. The Pull up R is still there. The results are same, I get identical waveforms. PH9/nSPISEL5 gets toggled along with SDCARD CS when I fire the command "modprobe mmc_spi" even if U54 buffer is removed from the ckt.

 

See last page of attached document for the updated HW block diagram for this experiment and signal waveforms.

 

Regards,

 

Ashish

 

SPI_Contention_20110702.doc

QuoteReplyEditDelete

 

 

2011-07-03 22:02:08     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 102057   

 

Thanks very much for your effort and update. Then I will set up a scope to see if the MMC driver will cause the PH9 to toggle, will be back to you.

QuoteReplyEditDelete

 

 

2011-07-04 07:27:44     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 102075   

 

I tried to bring up the mmc-spi add-on card on a BF527-ezkit, the software version is 2010R1, I made a couple of changes on the board file and do some hardware rework mainly to meet the requirements for card detection and chip-select, also to remove modules that may cause resource conflicts. The result is I can mount the /dev/mmcblk0p1 and read/write it well, I set a scope to single trigger mode to detect the PH9, however during the mount/umount, read/write cycle I did not see any output from the PH9.

 

I use chip_select = 1 and IRQ_PF8 for card detection.

 

So no idea why you have this issue, maybe you can try to check if there are other modules that manipulate on PH9, to start with a minimal system by comment out irrelevant modules in the board file might be a good option.

QuoteReplyEditDelete

 

 

2011-07-04 09:21:19     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 102077   

 

Hey Aaron,

 

Thanks for trying it out. One difference in your experiment that may / may not be significant is that you used a native SPISEL line mapped to SDCARD. Could you please check with with SDCARD driver mapped to PH12 as gpio (MAX_CTRL_CS + GPIO_PH12)? I know Ezkit has SDCARD connected to SSEL1, but for our experiment even if the sdcard driver is not able to mount the sdcard but still toggles PH9, we can conclude something's fishy.

 

Meanwhile, I will start with a minimal image (maybe just with sdcard to start with) and get back to you.

 

Thanks,

 

Ashish

QuoteReplyEditDelete

 

 

2011-07-05 11:39:28     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 102136   

 

Aaron,

 

Testing updates: -

 

-> I did a bare-metal program test using VDSP just to have one more check to ensure HW issues. I wrote a simple GPIO toggle program and toggled PH12 (SDCARD CS) using VDSP bare-meatal prgramming and excuted it using the JTAG ICE.

 

-> There was no activity on PH9 at all. It remained pulled high.

 

Regards,

 

Ashish

QuoteReplyEditDelete

 

 

2011-07-06 03:58:44     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 102166   

 

Some new findings: Which SPI mode do you use for you SPI MMC? If you are using mode 0 or mode 2, there is a risk that the chipselect behavior is not under the software controll, means the Linux SPI driver is no longer in charge of the CS toggling, the SPI hardware module inside the blackfin does. This may explain why you observed multiple CS activity on different CS PINs.

 

In the SPI driver, in the setup function we call bfin_spi_cs_enable, this means the cs enable flag will be set for all the spi board info entry, we suspect once any of your spi devices use mode 0 or mode 2, the CPHA will be set to 0 and CS will be controlled by hardware, since multiple enable flags are set, you may get multiple cs output.  Find some information in Documentation/blackfin/bfin-spi-notes.txt.

 

So the solution is, if any of your devices has to use mode 0 or mode 2, use gpio based cs controlling for all of them, so the PIN output will be controlled by GPIO module other than the SPI module, this will push the controll back to software

QuoteReplyEditDelete

 

 

2011-07-12 23:35:24     Re: SPI bus contention, SDCARD detect failure- 2010R1

Ashish Gupta (INDIA)

Message: 102381   

 

Dear Aaron,

 

I tried following things : -

 

1. Deleted all platform file entries for spi slaves except the sdcard. It gets mounted fine while booting up. So I could confirm your findings at my end.

 

2. Then I made all CS as gpios and this time there was no unnecessary toggling of CS.

 

Although your suggestion resolves the immediate problem, its not possible to fully utilize the Blackfin SPI port if we only use CS in gpio mode. There are some SPI slaves which need SPI CS toggling between each successive data transfer, like ADCs (which use the CS toggle as start conversion, I think even AD7606 does that). And in many cases, especially in the case of ADCs, we wud want to use SPI in DMA mode because we want a jitter free sample capture. Since Blackfin SPI controller toggles SPI CS (without SW intervention) under DMA mode in SPI mode 2, it is capable of being used in such a scenario. But if the linux drivers do not support a HW system where some slaves are connected to native SPI SSEL lines and some to the gpios then thats a big limitation. Because there is a significant merit in using a native SSEL for scenarios such as mentioned above.

 

How can we modify the Blackfin SPI driver to overcome this issue? Is it possible to submit a request for fixing this problem, if yes where do I need to submit that request?

 

Thanks for your efforts.

 

Regards

 

Ashish

QuoteReplyEditDelete

 

 

2011-07-13 02:13:58     Re: SPI bus contention, SDCARD detect failure- 2010R1

Aaron Wu (CHINA)

Message: 102382   

 

Then you may consider about two options:

 

1) If you CPU has 2 SPI controllers, assign a dedicated SPI controller for your ADC which require hardware CS

 

2)If you have only a single SPI controller, need to hack the current SPI code to enable the hardare CS while avoiding the random CS conflict as we met before. Remember that the conflication comes from the cs flag enablement in the probe function, once the controll of CS is passed to hardware, all the enabled CS lines will be toggled along with SPI data transfers automatically. So the work around is do NOT enable the CSs for all the device at the very beginning as we currently do, enable it right before each transfer instead. However this will lead to a new problem, if the flag bit are not enabled, then the CS PIN state is leaving in a uncertain state like hi, low, or hi-z, in your case you can choose to add pull-up or pull-down resistors for each of the CS lines according to your specific SPI device to avoid this risk.

Outcomes