I am using the Beagle Bone Black Rev C. It has a 4GB eMMC chip (EMMC04G-M627) on the MMC1 interface. When eMMC bus testing is performed with CMD19, the AM3358 peripheral waits for a CRC status (which the eMMC device rightfully doesn't provide per the JEDEC spec). This results in a data timeout (SD_STAT_DTO). If you reset the data state machine with SD_SYSCTL_SRD = 1, and continue the bus testing with CMD14, the eMMC device responds with the correct inverted data pattern.
This issue is identical to an issue listed in DRA7xx Silicon Errata SPRZ450: i836 "Bus Testing Commands CMD19 Incorrectly Waits for CRC Status Return". It does not appear in the AM335x errata.
I have written a driver for this interface which can be found here.
The problem can be recreated on a BeagleBone Black Rev C by initializing the eMCC device to the "Transfer" state, and then issuing a CMD19 with the corresponding data pattern as dictated by the JEDEC spec. Per the JEDEC spec the eMMC device does not respond with a CRC status after the CMD19 data transfer, but the AM3358 MMC peripheral waits for it anyway eventually resulting in a data timeout SD_STAT_DTO.
Below is the work around required to bypass the incorrect data timeout SD_STAT_DTO:
MmcStatus status = MmcSendCmd(mmc, 19, 0);
if (status != kMmcStatusSuccess) return status;
// Wait to write data.
while (!mmc->SD_PSTATE.BWE) {}
mmc->SD_DATA.raw = data;
// This is required due to a silicon bug:
// www.ti.com/.../sprz450.pdf
TimeDelayUs(5000); <===== DTO occurs sometime here.
mmc->SD_SYSCTL.SRD = 1;
while (!mmc->SD_SYSCTL.SRD) {}
while (mmc->SD_SYSCTL.SRD) {}
status = MmcSendCmd(mmc, 14, 0);
if (status != kMmcStatusSuccess) return status;
// Wait to read data.
while (!mmc->SD_PSTATE.BRE) {}
CMD19 is sent with the following SD_CMD values: {.INDX = 19, .DP = 1, .CICE = 1, .CCCE = 1, .RSP_TYPE = 2, .DDIR = 0, .BCE = 0}
