Data crc error

[new_alpha]

i got a error like this, in a custom carrier board for jetson nano.where its show the below error and rebooting , then it take around one and half minute to get the dashboard.

[ 39.728074] mmcblk1: error -110 sending stop command, original cmd response 0x900, card status 0x400900
[ 39.728087] mmcblk1: error -84 transferring data, sector 67373552, nr 1024, cmd response 0x900, card status 0x0
[ 39.744529] mmcblk1: retrying using single block read
[ 40.567012] mmc1: Data CRC error
[ 40.572849] sdhci: =========== REGISTER DUMP (mmc1)===========
[ 40.581379] sdhci: Sys addr: 0x00000400 | Version: 0x00000303
[ 40.611445] sdhci: Blk size: 0x00007200 | Blk cnt: 0x000003fb
[ 40.641591] sdhci: Argument: 0x04040df0 | Trn mode: 0x0000003b
[ 40.671765] sdhci: Present: 0x01fb0000 | Host ctl: 0x00000013
[ 40.701927] sdhci: Power: 0x00000001 | Blk gap: 0x00000000
[ 40.732073] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 40.762011] sdhci: Timeout: 0x0000000e | Int stat: 0x00000000
[ 40.791999] sdhci: Int enab: 0x02ff100b | Sig enab: 0x02fc100b
[ 40.821866] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 40.851625] sdhci: Caps: 0x376cd08c | Caps_1: 0x10006f77
[ 40.881270] sdhci: Cmd: 0x0000123a | Max curr: 0x00000000
[ 40.910468] sdhci: Host ctl2: 0x00003001
[ 40.937267] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x00000000ffefe410
[ 40.966906] sdhci: ===========================================
[ 40.996792] mmcblk1: error -110 sending stop command, original cmd response 0x900, card status 0x400900
[ 40.996800] mmcblk1: error -84 transferring data, sector 67374576, nr 1024, cmd response 0x900, card status 0x0
[ 41.010977] sdhci-tegra sdhci-tegra.2: Tuning done, restoring the best tap value : 44

where my sdhci@700b0400 look like this:

sdhci@700b0400 {
compatible = “nvidia,tegra210-sdhci”;
reg = <0x00 0x700b0400 0x00 0x200>;
interrupts = <0x00 0x13 0x04>;
aux-device-name = “sdhci-tegra.2”;
iommus = <0x30 0x1b>;
nvidia,runtime-pm-type = <0x00>;
clocks = <0x26 0x45 0x26 0xf3 0x26 0x136 0x26 0xc1>;
clock-names = “sdmmc\0pll_p\0pll_c4_out2\0sdmmc_legacy_tm”;
resets = <0x26 0x45>;
reset-names = “sdhci”;
status = “okay”;
tap-delay = <0x01>;
trim-delay = <0x03>;
mmc-ocr-mask = <0x00>;
max-clk-limit = <0xc28cb00>;
ddr-clk-limit = <0x2dc6c00>;
bus-width = <0x04>;
calib-3v3-offsets = <0x7d>;
calib-1v8-offsets = <0x7b7b>;
compad-vref-3v3 = <0x07>;
compad-vref-1v8 = <0x07>;
pll_source = “pll_p\0pll_c4_out2”;
keep-power-in-suspend;
ignore-pm-notify;
non-removable;
cap-mmc-highspeed;
cap-sd-highspeed;
nvidia,en-io-trim-volt;
nvidia,en-periodic-calib;
cd-inverted;
wp-inverted;
pwrdet-support;
nvidia,min-tap-delay = <0x6a>;
nvidia,max-tap-delay = <0xb9>;
pinctrl-names = “sdmmc_schmitt_enable\0sdmmc_schmitt_disable\0sdmmc_clk_schmitt_enable\0sdmmc_clk_schmitt_disable\0sdmmc_drv_code\0sdmmc_default_drv_code\0sdmmc_e_33v_enable\0sdmmc_e_33v_disable”;
pinctrl-0 = <0x8c>;
pinctrl-1 = <0x8d>;
pinctrl-2 = <0x8e>;
pinctrl-3 = <0x8f>;
pinctrl-4 = <0x90>;
pinctrl-5 = <0x91>;
pinctrl-6 = <0x92>;
pinctrl-7 = <0x93>;
vqmmc-supply = <0x3b>;
vmmc-supply = <0x4c>;
no-sdio;
no-mmc;
sd-uhs-sdr104;
sd-uhs-sdr50;
sd-uhs-sdr25;
sd-uhs-sdr12;
mmc-ddr-1_8v;
mmc-hs200-1_8v;
uhs-mask = <0x00>;
cd-gpios = <0x5b 0xca 0x00>;
linux,phandle = <0xba>;
phandle = <0xba>;

	prod-settings {
		#prod-cells = <0x03>;

		prod_c_ds {
			prod = <0x100 0xff0000 0x10000 0x1e0 0x0f 0x07 0x1e4 0x30077f7f 0x3000007d>;
		};

		prod_c_hs {
			prod = <0x100 0xff0000 0x10000 0x1e0 0x0f 0x07 0x1e4 0x30077f7f 0x3000007d>;
		};

		prod_c_sdr12 {
			prod = <0x100 0xff0000 0x10000 0x1e0 0x0f 0x07 0x1e4 0x30077f7f 0x30007b7b>;
		};

		prod_c_sdr25 {
			prod = <0x100 0xff0000 0x10000 0x1e0 0x0f 0x07 0x1e4 0x30077f7f 0x30007b7b>;
		};

		prod_c_sdr50 {
			prod = <0x100 0xff0000 0x10000 0x1c0 0xe000 0x8000 0x1e0 0x0f 0x07 0x1e4 0x30077f7f 0x30007b7b>;
		};

[WayneWWW]

Are you the one who made this carrier board or is it from some vendors?

[new_alpha]

its from some vendors.

[WayneWWW]

Please contact the board vendor.

We are not able to help as we don’t know the detail of their hardware design.

[new_alpha]

does this data crc always occur due to the vmmc power problem or got any other problem that make this data crc error?

[WayneWWW]

Mostly due to wrong software configuration.

Some of them related to wrong hardware design.

[new_alpha]

How can I identify whether the problem is with software or hardware? Can we find it using dmesg?

[WayneWWW]

Not able to identify. That is why board vendor is needed here.

[linuxdev]

The SD card itself could also be failing. Regarding vendor software, the device tree tells the drivers where to find various parts of hardware, and many pins have multiple possible functions. Vendors quite often use a slightly different layout compared to the reference board on the dev kits, which means the drivers which find things correctly on the dev kit will fail to find things on the custom carrier board. Only the vendor knows about the layout changes (and even power rails would fail if wrong).

[new_alpha]

hi,
I’ve observed that data CRC errors occur consistently with 64 GB and 128 GB SD cards, but not with 32 GB SD cards. This behavior has been consistent across multiple boards. Does anyone have insights into why this might be happening?thanks.

[linuxdev]

I’m probably wrong, but it sounds like the high order address bit is failing. That or the software sending the high order bit (e.g., a variable that isn’t designed to hold that high of a bit depth, not necessarily the communications of that bit). That’s a longshot, but something as simple as the wrong firmware not making that high order bit available could do this. Sorry, I don’t know enough about the SD card addressing to be more constructive than that, but if you know about the address scheme, then you might want to put it on a logic analyzer and see if the address is actually getting sent in full.