i.MXRT1170: FlexSPI, how to detect DQS timeout?

[michael_fischer]

Hello,

under normal condition DQS is used for the read strobe by the CPU. The connected device provides the read strobe. During communication SCLK and CS will be driven by the CPU. But if DQS fails from the connected device, SCLK will continue to be controlled by the CPU for a longer period of time and only later does the CPU abort the process.

Is it possible to set the time in which the CPU tries to maintain communication?

How can I determine that these errors have occurred in communication?

In our case the connected device is a FPGA, and we want to detect if there is an error in the communication.

I can provoke the error by approaching an area where the FPGA is not responding. But if I make a valid access again after that, FlexSPI from the CPU no longer responds. In this case I must reset the FlexSPI and setup again.

Best regards,
Michael

[martin_lapis]

Hello @michael_fischer 

Yes you are right. That is at least my understanding.
In MCR1.SEQTIMEOUT you set the maximum timeout the sequence of LUT commands must be finished. Otherwise the INTR[SEQTIMEOUT] is reported.

I see your ref_clk (root_clk) is 88MHz. Can you share your DLLxCR settings?

Martin

[michael_fischer]

Hello @martin_lapis ,

the DLLACR ist set to 0x00004900 that mean:

DLLACR[DLLEN]        = 0
DLLACR[DLLRESET]     = 0
DLLACR[SLVDLYTRAGET] = 0
DLLACR[OVRDEN]       = 1
DLLACR[OVRDVAL]      = 36

And our root clock will be set with:

   CLOCK_ControlGate(kCLOCK_Flexspi2, kCLOCK_Off);
   CLOCK_SetRootClockMux(kCLOCK_Root_Flexspi2, kCLOCK_FLEXSPI2_ClockRoot_MuxSysPll2Out);

   /* Set clock to 528 / 6 = 88 MHz */
   CLOCK_SetRootClockDiv(kCLOCK_Root_Flexspi2, 6);

   CLOCK_ControlGate (kCLOCK_Flexspi2, kCLOCK_On);

Best regards,
Michael

[Omar_Anguiano]

Unfortunately, this time is not adjustable. To determine the errors you might read the status registers. If DQS fails in timing it can be noticeable when an error in read/write is set.

If this happens you can reduce the communication speed so reset of the module might be avoided.

Best regards,
Omar

[michael_fischer]

Hello Omar,

but unfortunately I can't see any difference between a normal and a faulty transfer in the status registers. In both cases, the registers have the following values:

STS0 = 0x03
STS1 = 0x00
STS2 = 0x00

Or are there other registers I should look at here? 

Best regards,
Michael

[martin_lapis]

Hello @michael_fischer 

Could you attach content of INTR register as well? I am going to focus on IPCMDGE and AHBCMDGE values.

I am afraid that detection of missing DQS strobe is not possible in Flexspi. But detection of some kind of AHB/IP timeout would be possible.

Would that be solution in your case?

Martin

[michael_fischer]

Hello Martin,

if I enable the following FlexSPI interrupt bits SEQTIMEOUT and IPCMDERR with the following code:

   FLEXSPI2->INTR  = 0xFFFFFFFF;
   FLEXSPI2->INTEN = FLEXSPI_INTEN_SEQTIMEOUTEN_MASK | FLEXSPI_INTEN_IPCMDERREN_MASK;
   EnableIRQ(FLEXSPI2_IRQn);

It takes about 760ms from the end of the faulty access, here CS goes high, to enter the FLEXSPI2 interrupt handler.

Best regards,
Michael

[michael_fischer]

The variable MCR1[SEQWAIT]can be used to reduce the 760ms.

[michael_fischer]

Hello Martin,

thanks, this was a good hint. In case of an error the following extra bits was set in the INTR register:
- IPCMDERR
- SEQTIMEOUT

I just have to check when exactly these interrupts would come. I guess at the end of the cycle
if the 1170 has detected the error. I could measure that the access, CS, from the 1170 was only aborted after 5.9ms. If the interrupt comes only then, this is too late.

A normal read access can take up to 20us. I would try here if I can do a supervision this read access with a QTimer.

Best regards,
Michael

[Omar_Anguiano]

Unfortunately, there is no direct way for the device that the cause of the error is the DQS. Two possible errors due to the DQS is an error in AHB/IP on STS1 or a mismatch on the read/write values.

Best  regards,
Omar

[michael_fischer]

Hello @martin_lapis ,

it looks like that the timeout time can be controlled too. To do this, the MCR1[SEQWAIT] register must be used. The following information can be found about the register:

Command Sequence Wait
Sets wait time for command sequence. Command sequence execution times out and aborts after (SEQWAIT × 1024) serial root clock cycles. When this timeout occurs, if the interrupt is enabled (INTEN[SEQTIMEOUTEN]  = 1), an INTR[SEQTIMEOUT] interrupt is generated. Also, the arbitrator ignores AHB commands.
NOTE: You cannot write 0 to this field.

In our case the maximum access time is about 20us and our serial root clock is 88MHz. With a SEQWAIT of 4 the timeout is set to (1/88MHz * 1024 * 4) = 46.5us.

In addition the INTEN[SEQTIMEOUTEN] will be set. Here we will be informed by the interrupt if a sequence is faulty.

Can you confirm the functionality of the MCR1[SEQWAIT] register?

Best regards,
Michael