AnsweredAssumed Answered

imx6 EIM bus in busrt mode fails to read.

Question asked by Andreas Orfanos on Jul 7, 2017
Latest reply on Jul 7, 2017 by igorpadykov

Hello,

 

I am using a custom imx6 solo board, and I use EIM bus to access a FPGA. I use burst mode and I have observed some issues on the board when accessing the FPGA.. 

 

After investigating a board that was left in the failing state to access the FPGA, we were able to determine that the FPGA was still functioning correctly, and that writes to the FPGA (via the EIM bus) were successful. However, attempts to read from the FPGA failed completely, generally just returning garbage. After narrowing down to EIM read operations, we scanned through and read back all iMX6 registers related to the EIM peripheral and clock setup to see if there were any discrepancies from a standard working board. The only variation we found between the two was in the DLL Status Register (0x021b8098), which reports the status of the EIM peripheral read DLL that is used to re-sync the internal BCLK for sampling data read back from the bus. The values in this register indicated that in the faulty board the delay value that the EIM read DLL had locked to was significantly greater than is usually seen on a working board (80 delay line taps on the faulty machine vs 24 on the standard machine). There is a manual override provided for this value in the EIM DLL Control Register (0x021b8094) - entering the standard delay value from the working board into this register on the faulty board recovered FPGA reads. When the override was removed, the old delay value was re-instated and the FPGA reads went back to the fail state. Interestingly, attempts to reset the DLL using the DLL Reset Bit in the EIM DLL Control Register did not result in the delay value being updated on the faulty board (or at least, not changed from the "erroneous" value). However, when monitoring the locked delay value on the standard board, it was possible to see the value changing around slightly every so often, so this value must be constantly updated by the DLL (as you would expect). Power cycling the faulty board resulted in the delay value coming back up at the same value as the standard machine, and FPGA reads worked with no issues.

 

Have you come across / are you aware of any issues related to this DLL or similar problems with the EIM bus? I did a search of the errata for the device as was unable to find anything referencing the kind of issue we are seeing. Any suggestions or input you can give would be very much appreciated.

Outcomes