[Bug 1001764] New: Enhancement of MMC/SD over SPI driver

[Bug 1001764] New: Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

            Bug ID: 1001764
           Summary: Enhancement of MMC/SD over SPI driver
           Product: eCos
           Version: CVS
            Target: All
  Architecture/Host Other
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Disk
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: ilijas@siva.com.mk
                CC: ecos-bugs@ecos.sourceware.org

Created attachment 2094
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2094&action=edit
Enhanced MMC/SD over SPI driver

Original MMC/SD driver supports only Standard Capacity SD cards, besides MMC.
SDSC is becoming increasingly hard to find on the market, while SDHC are
largely available. This bug introduces support for SDHC cards. No attempt was
made to support newer MMC cards. It's been tested with these cards:
MMC Standard 16MB
MMC Standard 32MB
SD Standard Capacity 512MB
SD Standard Capacity 2GB
SD High Capacity 8GB

All cards were tested on both ST32 and Kinetis K60 platforms. SD cards were
tested on Kinetis K70 platform too.

I had no SD Extended Capacity at hand, but, according to SD Physical Layer
Simplified Specification Ver_3.01, it should work also with SDEC cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Mike Jones <mjones@linear.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjones@linear.com

--- Comment #1 from Mike Jones <mjones@linear.com> ---
I tested this with SD 2GB, SD 4GB, SD 8GB using Tower K60. Works fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #2 from Mike Jones <mjones@linear.com> ---
Worked with Micro 2GB and 8GB. Did not work with Micro 4GB.

All the cards I tested were SanDisk except the Micro 4GB which was Samsung. I
tested two brand new Samsung 4GB and they both mount on Linux properly and were
formatted by the Linux Disk Manager like the other cards. All FAT32.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #3 from Ilija Stanislevik <ilijas@siva.com.mk> ---
(In reply to comment #2)
> Worked with Micro 2GB and 8GB. Did not work with Micro 4GB.
> 
> All the cards I tested were SanDisk except the Micro 4GB which was Samsung.

Mike,

I am trying to repeat your test with 4GB card. Can you give me the model name
of the one you have tried?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #4 from Mike Jones <mjones@linear.com> ---
Samsung Model MB-MS4GB 
Class 4 Micro SDHC

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #5 from Ilija Stanislevik <ilijas@siva.com.mk> ---
(In reply to comment #4)
I couldn't find this model, so I can't repeat your test. Tried with Transcend
brand 4GB class 4 SDHC and it works.

Mike, can you locate the point where the driver fails? Maybe you can present
some printout with DEBUG enabled.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #8 from Ilija Stanislevik <ilijas@siva.com.mk> ---
Created attachment 2132
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2132&action=edit
Patch in light of bug 1001676

This might be related to bug 1001676. This is a patch suggested by Ilija Kocho.
Mike, can you try your 4GB card with this patch on dspi driver?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #9 from Mike Jones <mjones@linear.com> ---
I tried the patch but the behavior is exactly the same. I don't have other
cards with me, so I don't know if it impacted behavior of other cards.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #10 from Mike Jones <mjones@linear.com> ---
I have verified that this patch did not harm with a 2GB and 8GB SanDisk. I
don't have time to debug the Samsung card now. If the cost is not too great, I
can ship a 4GB Samsung card to someone interested in debugging it. If someone
is willing to debug, e-mail me an address so I can check the shipping costs.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEEDINFO
                 CC|                            |ilijak@siva.com.mk
     Ever confirmed|0                           |1

--- Comment #11 from Ilija Kocho <ilijak@siva.com.mk> ---
Mike

We need to figure-out where is the problem, The card or MMC driver or some of
SPI drivers. I tried to get Samsung SD card in several EU countries but failed.
Can you please do some tests for us?

Can you do post a screen capture of diagnostic output from minicom? (text
captyre preferable to screen).

Also if possible please try with different platforms: Kinetis, STM32, etc and
see if it makes difference.

Thanks
Ilija

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #12 from Mike Jones <mjones@linear.com> ---
Due to heavy load, I can't do much until first two weeks of May. I'll put this
on my priority list for early May. If there is some opportunity for free time,
I'll send what I can early.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #14 from Mike Jones <mjones@linear.com> ---
I took several micro cards and plugged them into the larger carrier and tested
on the K60 Tower, leaving the code to use response[3].

The SanDisk Ultra 8GB micro SDHC 1 does not respond to the init command 40 00
00 00 00 95.

The Samsung 4GB micro SDHC discussed earlier and having problems does not
respond to init command 40 00 00 00 00 95.

The SanDisk 2GB micro SD responds to the init command... and fails in this
code:

    if ( 1 == disk->sd_csd_version) {
      // There is information available about the file format, e.g.
      // partitioned vs. simple FAT. With the current version of the
      // generic disk code this needs to be known statically, via
      // the mbr field of the disk channel structure. If the card
      // is inappropriately formatted, reject the mount request.
      if ((0 != MMC_CSD_REGISTER_FILE_FORMAT_GROUP(&csd)) ||
          (0 != MMC_CSD_REGISTER_FILE_FORMAT(&csd))) {
          return -ENOTDIR;
      }
    } // Acco

Just like the SD 2GB mentioned in the last comment. Next steps will be to move
to my custom board with micro connector and test.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #15 from Mike Jones <mjones@linear.com> ---
On the hardware with micro SD, the return from 48 00 00 01 AA 87 on my 2GB
micro SD card puts the 01 in response[2] and the AA in response[3] which means
the original code works with my custom board..

So now differences. The Tower K60 is Rev 1 silicon and the custom board is Rev
2 silicon. The revisions in my CDL are correct.

The Tower is using a fx patched packages, and the custom is not, so I
differenced the trees and found no MMC/SD or SPI related differences.

So at this point the differences are silicon and board. The failing board is
the Tower K60 large SD card socket with old silicon, and the working board is a
custom K60 board with micro SD card socket.

I now move to the original problem Samsung card.

In this code:

  if (MMC_REPLY_ILLEGAL_COMMAND & reply) { // V1 cards do not understand CMD8
    disk->sd_version = 1;
    disk->sd_capacity = STANDARD_CAPACITY;
    mmc_spi_end_command(disk);
    return ENOERR;
  }

It enters as a V1 card. I don't have the Beagle attached yet. But this is the
difference from the working cards.

It then fails to enter the idle state.

I'll get the Beagle on it later.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #18 from Mike Jones <mjones@linear.com> ---
After brining up a custom K60 FXM board and testing, I have come to the
following conclusion:

1) My Tower hardware has been damaged 
2) The MMC patches are OK and problems I reported are related to the damaged
hardware
3) The 4GB Samsung card/s still do not work, even on the new board

Conclusion 2 is based on logical reasoning and observation, not a discovery of
root cause. It is always possible the problem is human error, or related to the
P1 K60 silicon.

I am traveling and will try to obtain other Samsung cards from the same vendor
so I can test them and find out if the problem is vendor or card specific.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #19 from Mike Jones <mjones@linear.com> ---
I am having some bad behavior in the SPI code when using MMC patch with FXM
with a stable application I used prior to FXM. Let me be upfront and say that I
did find some bad application code that was writing over memory when processing
some va_args, and I can't rule out other application errors, but I have
constrained the application code and very carefully looked at potential memory
issues, even looking at every sprintf for issues with formatting. So error free
application code is only an assumption.

(If anyone has suggestions on how to string process with type safety in an eCos
application, please offer advice. I assume it would have to be some C++
library, possibly with templates. I don't know what is practical within the
cortex tool chain.)

The application uses I2C, and an SD card. It reads lots of data from I2C and
writes to the SD card, but never at the same time.

The problem is a struct pointing to the SPI dev ends up with an address of
0xFFFFFFFF and this causes an exception 5. This happens in the SPI code inside
one call. During this call, all other threads are blocked.

I will describe where this happens in code and hope someone has ideas on how to
debug it, or perhaps the author might see something that indicates a possible
driver bug.

By instrumenting the code as follows:

cyg_spi_transaction_transfer(cyg_spi_device* device, cyg_bool polled,
                             cyg_uint32 count, const cyg_uint8* tx_data,
cyg_uint8* rx_data,
                             cyg_bool drop_cs)
{
    cyg_spi_bus*    bus;
    CYG_CHECK_DATA_PTR(device, "valid SPI device pointer required");

    if(tx_data == 0xFFFFFFFF || rx_data == 0xFFFFFFFF || device == 0xFFFFFFFF)
        return;

    if (device->spi_bus == 0xFFFFFFFF)
        return; 

    bus = device->spi_bus;

    if(bus->spi_transaction_transfer == NULL || bus->spi_transaction_transfer
== 0xFFFFFFFF)
        return;

    CYG_CHECK_DATA_PTR(bus, "SPI device does not point at a valid bus
structure");
    CYG_ASSERT(bus->spi_current_device == device, "SPI transfer requested
without claiming the bus");
    CYG_CHECK_FUNC_PTR(bus->spi_transaction_transfer, "SPI device has not
provided a transfer function");
    (*(bus->spi_transaction_transfer))(device, polled, count, tx_data, rx_data,
drop_cs);
}

Eventually it will break on the first return and device will be 0xFFFFFFFF.

By looking at the call chain, the problem occurs:

mmc_spi_send_command_start(cyg_mmc_spi_disk_info_t* disk, cyg_uint32 command,
cyg_uint32 arg)
{
    cyg_spi_device* dev = disk->mmc_spi_dev;
    cyg_uint8       request[7];
    cyg_uint8       response[7];
    cyg_uint8       reply;
    int             i;

...

    reply       = response[6];
    for (i = 0; (i < MMC_SPI_COMMAND_RETRIES) && (0 != (reply & 0x0080)); i++)
{
        cyg_spi_transaction_transfer(dev, cyg_mmc_spi_polled, 1,
mmc_spi_ff_data, response, 0);
        reply = response[0];

in the retry loop. Before this in the code with ... is also a
cyg_spi_transaction_transfer call. The bad address NEVER occurs on the first
use of transfer, and ALWAYS occurs in the second call to transfer, but only
after running a long time.

If I examine variables in mmc_spi_send_command_start, the disk->mmc_spi_dev has
a good address, and dev does not. This implies that somewhere between the
assignment at the top and the retry loop it gets overwritten.

The underlying code is using the request and reply arrays, possibly with DMA. I
don't see any simple way to explain the messed up address, as the dev address
is lower than the arrays. All F's is also an unusual value, other than the 512
byte buffer for sending FFs to the device to clear it. But that is pretty much
static data, so it would require a copy to cause this problem.

Also, note that the I2C is reading on a 100ms interval from a counter/timer,
and then writing to SD. The application runs for several minutes before the
problem occurs. So the code is basically performing the same operation every
100ms and then after some time fails.

I created some test code to malloc all 16M of the memory and test with 0x55 and
0xAA, and a counter, etc, and I don't get any memory failures. I basically
malloc in 100K chunks, test, and then free at the end, and then do it again,
etc. So I believe the underlying memory system is ok.

Does anyone have ideas that might help narrow this down?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #20 from Mike Jones <mjones@linear.com> ---
After getting some help from Ilija and a lot of debugging, I believe the
exception problem is limited only to FXM. My application is quite stable on
non-FXM hardware. My application is quite stable when I disable SPI DMA on FXM.
The problem seems to be related to DMA with FXM. Any further discussion from me
will be moved to the FXM bug.

Therefore, from my point of view, the only real issue with MMC is the problem
Samsung card, which I think could be ignored for now and the code could be
committed to CVS. The failing card came from a retailer that is known to sell
old products from time to time and I doubt anyone will have a problem.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Stanislevik <ilijas@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2132|0                           |1
        is obsolete|                            |

--- Comment #21 from Ilija Stanislevik <ilijas@siva.com.mk> ---
Comment on attachment 2132
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2132
Patch in light of bug 1001676

Obsoleted as it's been proven useless.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #22 from Mike Jones <mjones@linear.com> ---
I have had more bench time on the MMC, so I have more information about its
operation under heavy use.

First, my setup is atypical. I have a cable on J5 of the Kinetis tower board
that connects to another board 30cm away. This board has its own power supply
off line. Therefore, because there is a ground connection in J5, there is a
ground loop. Furthermore, I am using the I2C lines in the J5 connector.

I have seen four problems:

1) Can't mount Samsung microSD
2) Can't mount any microSD
3) IO failure after three hours of intense operation (logging MB to card)
4) Can't get DMA to work reliably

I have some new information. I was debugging the TWR-DACADC-LTC and noticed
problem 2. When I removed the ground clips from my scope, problem 2 went away.
This leads me to the conclusion that problems 2 and 3 are related to grounding
problems. I can't prove grounding is causing 3 until I have a single board
version of my solution.

Problems 1 and 4 still seem to be problems that only affect me. I work around
them by not using DMA and not using the Samsung card. I am certain that problem
1 is not related to grounding. I have tested for that. I am reasonable certain
problem 4 is not related to grounding, I am pretty sure I have seen the problem
with my cable removed.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> ---
It seem that the Samsung card is a kind of singularity as far I understand it's
a single instance. I couldn't find one to try. All other cards work properly. I
wouldn't hold the driver just for a single instance, so I am going to commit.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

--- Comment #24 from Mike Jones <mjones@linear.com> ---
Thank you. I see no reason not to commit it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |RESOLVED
         Resolution|---                         |CURRENTRELEASE

--- Comment #25 from Ilija Kocho <ilijak@siva.com.mk> ---
Checked in.

Thanks to Ilija Stanislevik for the patch and to Muke Jones for testing.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 1001764] New: Enhancement of MMC/SD over SPI driver

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001764

            Bug ID: 1001764
           Summary: Enhancement of MMC/SD over SPI driver
           Product: eCos
           Version: CVS
            Target: All
  Architecture/Host Other
                OS:
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: low
         Component: Disk
          Assignee: unassigned@bugs.ecos.sourceware.org
          Reporter: ilijas@siva.com.mk
                CC: ecos-bugs@ecos.sourceware.org

Created attachment 2094
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2094&action=edit
Enhanced MMC/SD over SPI driver

Original MMC/SD driver supports only Standard Capacity SD cards, besides MMC.
SDSC is becoming increasingly hard to find on the market, while SDHC are
largely available. This bug introduces support for SDHC cards. No attempt was
made to support newer MMC cards. It's been tested with these cards:
MMC Standard 16MB
MMC Standard 32MB
SD Standard Capacity 512MB
SD Standard Capacity 2GB
SD High Capacity 8GB

All cards were tested on both ST32 and Kinetis K60 platforms. SD cards were
tested on Kinetis K70 platform too.

I had no SD Extended Capacity at hand, but, according to SD Physical Layer
Simplified Specification Ver_3.01, it should work also with SDEC cards.

-- 
You are receiving this mail because:
You are on the CC list for the bug.