Multi Block Read/Write in esdhc driver for P1015 Platform

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

Multi Block Read/Write in esdhc driver for P1015 Platform

1,319 Views
muhammad_qasim
Contributor I

Hi

I am facing problem while transferring multiple blocks read/write in esdhc driver for P1015 Platform. However eSDHC Driver is working fine in single block read/write both with DMA/without DMA support. I have tried the same driver on imx25pdk and multiple block read/write is working fine.

First Read/Write of multiple blocks Transfer is complete successfully but after then no R/W of multiple block is executed and card goes to some undefined state.

Is P1015 supports multiple block read/write? If yes, any type of errata/workaround should be considered?

Labels (1)
0 Kudos
4 Replies

544 Views
lunminliang
NXP Employee
NXP Employee

Please see following comment from freescale engineer.

The P1015 eSDHC has to support Read/Write of multiple blocks.

The P1024/P1015 errata document is not available yet. Some known problems with the eSDHC controller see on Cross Reference: sdhci-of-esdhc.c pages. For example see http://code.metager.de/source/history/linux/stable/drivers/mmc/host/sdhci-of-esdhc.c

You also should check for the next possible problem:

BLKATTR[BLKCNT] does not return to 0 after Transfer Complete for multi-block transfer

Description: For a multi-block transfer, when the XFERTYP[BCEN](block count enable) is 1, BLKATTR[BLKCNT] should decrement to 0 after Transfer Complete (TC)((IRQSTAT[TC] = 1). However, due to this erratum, BLKATTR[BLKCNT] returns to the initial value which was programmed while issuing the multi-block transfer command.

Impact: The value of BLKATTR[BLKCNT] is unreliable and cannot be read to confirm a Transfer Complete.

Workaround: For a multi-block transfer, after IRQSTAT[TC] = 1, software should not rely on the value of BLKATTR[BLKCNT].


544 Views
muhammad_qasim
Contributor I

Hi

Driver is already not relying on BLKATTR[BLKCNT] bit. So this workaround could not apply in current case.

Also issues discussed at "http://code.metager.de/source/history/linux/stable/drivers/mmc/host/sdhci-of-esdhc.c" seems not relevant to Multi Block transfer. I have tried one of the issue "disable CMD23 for some Freescale SoCs" mentioned at above link but it is also not compatible with current scenario.

Currently, Driver is successfully WRITING Multi Block Transfer 5 times [Block Size = 512, No of Blocks = 3] => 5 * 3 * 512B After first successful READ Multi Block [Block Size = 512, No of Blocks = 3], Driver Data Line PRSSTAT[DLA] goes to inactive state,  PRSSTAT[SDOFF] bit is clear and IRQSTAT[BRR] is clear means "Not ready to read buffer". So second Multi Block Call is unsuccessful.  

0 Kudos

544 Views
lunminliang
NXP Employee
NXP Employee

Does the problem occur on all the boards, or just some of the boards? Which SDK release version do you use?

Also see the erratum which can lead to the problem:

A-004577:  PRSSTAT[DLA] bit does not reflect the data line state when any command with busy (R1b) is issued

Affects: eSDHC

Description: When an AutoCMD12 or any command with busy (R1b) is issued, PRSSTAT[DLA] bit should reflect the data line state. However, due to this erratum, PRSSTAT[DLA] is not applicable to detect data busy state.

Furthermore, the corresponding transfer complete interrupt is not generated.

However, the AutoCMD12 or any command with busy (R1b) can still be used with the restriction that busy needs to be de-asserted before sending new data command.

Impact: When an AutoCMD12 or any command with busy (R1b) is issued, PRSSTAT[DLA] bit does not reliably reflect the data line state.

Workaround: Software needs to wait for busy de-assertion before issuing any new data command. DAT0 line could be polled, but robust solution would be to keep sending CMD13(SEND_STATUS) until card reaches "trans" state.

. For AutoCMD12, CMD13 needs to be sent after TC of the data transfer command for which AutoCMD12 is enabled.

. For other command with busy, CMD13 needs to be sent after the command with busy completion(IRQSTAT[CC] = 1).

Fix plan: No plans to fix

0 Kudos

544 Views
rautaioan-alin
Contributor I

Hi !

I'm facing a similar issue when using CMD25 to write multiple blocks on p1024rdb board. Only the first write is successful. The second multiple write can't be done.

I've selected AutoCMD12 and issued the multiple write command (by following the steps described at Normal write section of P1024rdb RM). Then I got transfer complete bit set and also data timeout error.

Multiple read command, single read and single write, all seem to work just fine.

Also, if I issue a multiple read after the first multiple write then the read will work. My problem is I can't get 2 consecutive multiple block writes working.

If I don't select AutoCMD12 for mutiple write operations and if I issue the stop command by myself after every multiple block write, then my issue is solved, but this is only an workaround and I can't rely on it.

Is there any p1024 chip errata available ?

Has someone got into the same issue and found a reliable solution ?

Thank you in advance,

Alin

0 Kudos