LPC1788 MCI problems...

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC1788 MCI problems...

1,292 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fsteff on Fri Jul 20 06:13:28 MST 2012
Hi,

I've been trying to debug my usage of the lpc177x_8x_mci.c example code (an olding one, and one cloned from git a few days ago), but continue to have some very annoying problems testing with this 16GB SDHC card.
I see the problem only the first time I call either MCI_ReadBlock() or MCI_WriteBlock().
The problem exists both in DMA and FIFO mode.

The commands both return MCI_FUNC_OK as expected, and I start polling MCI_GetDataXferEndState(), to wait for the data to be transfered.

However I have three types of error to happen during this wait.

1. After a few while() loops, MCI_GetDataXferEndState() returns 0 and MCI_GetXferErrState() also returns 0 to indicate the transfer has completed without errors. However the contents of the buffer has not been touched by the DMA.

2. After a many while() loops, MCI_GetDataXferEndState() returns 0 and MCI_GetXferErrState() returns 2, indicating MCI_DATA_CRC_FAIL.

3. After a very many while() loops, MCI_GetDataXferEndState() returns 0 and MCI_GetXferErrState() returns 8, indicating MCI_DATA_TIMEOUT.

It seems like the first time I call MCI_ReadBlock() or MCI_WriteBlock() it sets up something during it's course that should have been set up before the first call, as the next many calls to the same function always seems to performs as expected.

I fail to spot any (vital) differences in the LPC registers relavant to either of the functions (save to CSV file before and after command execusion and then manually compared), and have been single-stepping through all of the functions, too.

Any advice or pointers any of you can provide to help me debug this problem?

--
Flemming
Labels (1)
0 Kudos
11 Replies

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Nemuisan on Tue Apr 05 18:47:18 MST 2016
Hi All.

[s]I've ported ChaN's FatFs into LPC1788(MCI Interface).
My example based on ChaN's LPC2388 MCI-Driver.
http://nemuisan.blog.bai.ne.jp/?eid=192848#LPC1788
Which can also support SDHC(I confirmed upto 32GB Capacity!).[/s]

LPC1788 example was deprecated.
Use LPC4088 Example instead.

It supports upto 128GB capacity and eMMCv5.
http://nemuisan.blog.bai.ne.jp/?eid=192848#LPC4088

Enjoy this.

Nemui
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wmues on Tue Apr 14 08:12:41 MST 2015
I got the permission from managment to put my MCI driver online with a BSD-style licence.

The driver is appended to this post (login required to see it).

Have fun...

NOTE: there is an error in the SDHC capacity calculation.
The correct formula is:

mmc_card_sectors = (get_field(response, 48, 22) + 1) << 10;

0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Dave on Thu Mar 21 09:00:23 MST 2013
Pretty much... it's a mechanism to cycle the power on the MCI card...  just in case a hard reset is necessary... for any reason...
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Imagineme on Mon Dec 17 06:40:40 MST 2012
SO in other words is it`s not a vital signal its only used as a precaution if the transfer between the sd card and MCU has to be terminated and start start again/ reset/.
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wmues on Sun Dec 16 15:12:57 MST 2012
The SD card has no reset pin. When the communication get stuck, only a power cycle will reestablisch the connection.

This should not happen if the driver software is crafted carefully, and you will found many products which do not use a power cycle mechanism.
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Imagineme on Sun Dec 16 10:40:13 MST 2012
Can anyone explain me the usage of SD_PWR pin what is it`s purpose ?
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Lien.Nguyen on Mon Jul 23 03:10:32 MST 2012
The MCI driver has been updated for SDHC. You can pull it from GIT server.
Please go to http://sw.lpcware.com/?p=lpc177x_8x.git&a=summary

Best Regards,
Lien
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Lien.Nguyen on Mon Jul 23 03:05:38 MST 2012
Hi,
I think that the timeout for read/write operations should be increased.
Please try updating DATA_TIMER_VALUE macro in lpc177x_8x_mci.h. This value will be set to MCIDataTimer register.

Best Regards,
Lien
0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by fsteff on Mon Jul 23 00:38:46 MST 2012
Thanks for your replies, wmues and Dave,

I'm also pretty dissapointed with the state of the NXP code, but I did get it to work fine with an MMC card so the upgrade to a SDHC card ought to be manageable.

Still looking for pointers to what might be wrong.

--
Flemming


0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Dave on Sun Jul 22 13:10:12 MST 2012
Yeah, I wasn't that impressed either...  The code using Chan's library comes with a monitor program that really didn't do anything - except the status command, which seemed to hang initially, but eventually gave me some of the details about the card.  The other example (the one that uses the EFSL) did a little more, like give me the directory contents etc...

Either way, they're pretty lame.  I ended up writing my own as well, both for the MCI interface and the SPI interface...

Chan's stuff works great for the SPI interface...

0 Kudos

928 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wmues on Sun Jul 22 03:37:48 MST 2012
IMHO,

the MCI code from NXP is horrible.

I have done my own - I was not able to get this code to do something reliable.
0 Kudos