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
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!
-----------------------------------------------------------------------------------------------------------------------
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?