AnsweredAssumed Answered

i.MX RT1064 uSDHC Transfer Complete Interrupt Not Generated

Question asked by Daniel Burgoyne on Mar 25, 2019
Latest reply on Mar 27, 2019 by Takashi Kashiwagi

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?

Outcomes