I'm working on a uSDHC driver using the MIMXRT1064-EVK evaluation board. The transfer complete interrupt is not getting generated at the completion of an erase command (CMD38). The relevant part of the i.MX RT1064 reference manual is found on page 1624, Command Inhibit (DATA) flag of the PRES_STATE register.
Command Inhibit (DATA)
This status bit is generated if either the DAT Line Active or the Read Transfer Active is set to 1. If this bit
is 0, it indicates that the uSDHC can issue the next SD / MMC Command. Commands with a busy signal
belong to Command Inhibit (DATA) (for example. R1b, R5b type). Changing from 1 to 0 generates a
Transfer Complete interrupt in the Interrupt Status register.
NOTE: The SD Host Driver can save registers for a suspend transaction after this bit has changed from
1 to 0.
0b - Can issue command which uses the DATA line
1b - Cannot issue command which uses the DATA line
Below is a sequence of reads of the PRES_STATE register during the transaction in question. As you can see, the Command Inhibit (DATA) flag is clearly set at the beginning and then unset at the end of the transaction. However, no interrupt is generated. I confirmed this by examining the INT_STATUS register in a debugger as well as breaking on all transfer complete interrupts. Further, I have successfully received the transfer complete interrupt for a read transaction so I know I have everything configured/enabled correctly.
TIME: 1001ms PRES_STATE: 0xff898089
TIME: 1001ms PRES_STATE: 0xfe89800e
TIME: 1003ms PRES_STATE: 0xfe89800e
TIME: 1005ms PRES_STATE: 0xfe89800e
TIME: 1007ms PRES_STATE: 0xfe89800e
TIME: 1010ms PRES_STATE: 0xfe89800e
TIME: 1010ms PRES_STATE: 0xff898088
The reference manual quoted above clearly states that the transfer complete interrupt is generated when the Command Inhibit (DATA) flag changes from a 1 to a 0. Which, it clearly does in the sequence above (NOTE the bit in question is bit 1).
Why is the transfer complete interrupt not generated? Could this be a bug with the chip?
Hi Daniel
> The transfer complete interrupt is not getting generated at the completion of an erase command (CMD38).
Please tell me the condition of the card at that time. Does the SD card accept other commands after the problem occurs?
Also, does the problem change with CMD18(Read) or CMD25(Write)?
I have seen a problem that Transfer complete is not occurred with CMD25.
The cause at this time is that a pin setting of VSELECT is not correct (it was my miss....).
So if the SD card no longer accepts commands after the problem occurs, I think the pin setting of VSELECT is not correct.
Please Check IOMUXC_GPIO_B1_14_USDHC1_VSELECT in Board_InitUSDHCPins.
(The setting of Board_InitUSDHCPins in the project template of SDKv2.5.0 was incomplete......)
Best Regards,
T.Kashiwagi
I've now also configured the VSELECT pin and the behavior is unchanged.
Hi Daniel
> I've now also configured the VSELECT pin and the behavior is unchanged.
understood. It seems that the problem is different from the one I have seen.
If possible, I recommend using an SD protocol analyzer to check that erase sequence(CMD32/33/38) on SD bus.
Best Regards,
T.Kashiwagi
Hi Takashi,
Thanks for taking the time to reply.
The SD card remains in a good condition and will successfully complete CMD18 (read) and CMD25 (write) commands so long as I wait for the Command Inhibit (Data) flag to clear before issuing the next request. I also successfully receive the transfer complete interrupt for CMD18/25.
At this time I do not configure or use the VSELECT pin. I'm not currently switching to low voltage signaling. I will try configuring it anyway though and see if it makes any difference.
Thanks