SDHC nibble swap problem in iMX6ULL

[mmar]

I am working with iMX6ULL and compiling from SDK_2.2 the demo boards/evkmcimx6ull/driver_example/sdcard/freertos/.

When I read from a uSD I have a nibble swap problem. The data in uSD is

0xd1 0x00 0x20 0x41 0x00 0x20

but I read

0xd0 0x10 0x24 0x01 0x02 0x00

an so on...

After several hours inspecting the code, I found the register uSDHCx_MIX_CTRL which has the bit 6 "NIBBLE_POS" than can be set to 0 or 1. After setting it to zero, I finally read the data correct from uSD.

The question is: in the driver_example demo, in the file fsl_host.h the macro

#define HOST_ENABLE_DDR_MODE(base, flag) (USDHC_EnableDDRMode(base, flag, 1U))

calls the function USDHC_EnableDDRMode() with the third parameters always set to 1 (this parameter is used to set the NIBBLE_POS in uSDHCx_MIX_CTRL register, I need zero to work correctly).

Why this value is fixed to 1? Shouldn't It be auto-detected?

Now that I set it to zero, how can I be sure it will work with all SD cards vendors?

Thanks in advance for the support

[igorpadykov]

Hi Manual

seems both read and write should be performed with the same "NIBBLE_POS" setting,

then there should be no problems and this does not depend on card vendor.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mmar]

Hi Igor,

and thanks for your reply. You are right, if I write and then read with the same "NIBBLE_POS" setting, I always read and write the same thing. The driver example in the SDK do this.

But I was reading an SD card previously written by a personal computer. The data written by my personal computer required a NIBBLE_POS different from the NXP driver example.

Should there be a standard, shouldn't it? If my personal computer follow the standard, why NXP driver example was the opposite?

Am I the only one which experienced this "reverse" behaviour?