i.MX Processors中的主题 Re: IMX51 Synchronous mode issue

IMX51 Synchronous mode issue

DeepakKukreja — Thu, 01 Feb 2018 12:29:42 GMT

Hi,

I have iMX51 board with WINCE700, I am trying to make use of Synchronous Burst mode write to increase the throughput on the WEIM Bus.

I have an FPGA connected onto the WEIM CS0 port. I am using 16 bit multiplexed access.

The problem is that the BCLK pad appears tristated and the BCLK clock cycles seem to be riding over this tristated signal, The write is being performed as I can see the CS, WR and ADV/LBA signals being generated.

Here is the configuration that I have done for the WEIM Module:

CS0GCR1 (32 BIT) .... 0x60011C3B

(*) CSEN ... 0x01 (*) SWR .... 0x01 (*) SRD .... 0x00
(*) MUM .... 0x01 (*) WFL .... 0x01 (*) RFL .... 0x01
(*) CRE .... 0x00 (*) CREP ... 0x00 (*) BL ..... 0x04
(*) WC ..... 0x01 (*) BCD .... 0x01 (*) BCS .... 0x00
(*) DSZ .... 0x01 (*) SP ..... 0x00 (*) CSREC .. 0x00
(*) AUS .... 0x00 (*) GBC .... 0x00 (*) WP ..... 0x00
(*) PSZ .... 0x06

CS0GCR2 (32 BIT) .... 0x00000002

(*) ADH .... 0x02 (*) DAPS ... 0x00 (*) DAE .... 0x00
(*) DAP .... 0x00

CS0RCR1 (32 BIT) .... 0x20475230

(*) RCSN ... 0x00 (*) RCSA ... 0x03 (*) OEN .... 0x02
(*) OEA .... 0x05 (*) RADVN .. 0x07 (*) RAL .... 0x00
(*) RADVA .. 0x04 (*) RWSC ... 0x20

CS0RCR2 (32 BIT) .... 0x00000000

(*) RBEN ... 0x00 (*) RBE .... 0x00 (*) RBEA ... 0x00
(*) RL ..... 0x00 (*) PAT .... 0x00 (*) APR .... 0x00

CS0WCR1 (32 BIT) .... 0x48000000

(*) WCSN ... 0x00 (*) WCSA ... 0x00 (*) WEN .... 0x00
(*) WEA .... 0x00 (*) WBEN ... 0x00 (*) WBEA ... 0x00
(*) WADVN .. 0x00 (*) WADVA .. 0x00 (*) WWSC ... 0x08
(*) WBED ... 0x01 (*) WAL .... 0x00

CS0WCR2 (32 BIT) .... 0x00000000

(*) WBCDD .. 0x00

WEIM Configuration Register (32 BIT) .... 0x00000020

(*) WDOG_LIM 0x00 (*) WDOG_EN. 0x00 (*) INTPOL . 0x01
(*) INTEN .. 0x00 (*) GBCD ... 0x00 (*) BCM .... 0x00

Since there seems to be something amiss regarding the WEIM configuratioin register addresses, below are the register address that I am using

#define WEIM_ADDR_CONFIG_CS0GCR1 (0x83FD8000 + 0x2000)
#define WEIM_ADDR_CONFIG_CS0GCR2 (0x83FD8000 + 0x2004)
#define WEIM_ADDR_CONFIG_CS0RCR1 (0x83FD8000 + 0x2008)
#define WEIM_ADDR_CONFIG_CS0RCR2 (0x83FD8000 + 0x200C)
#define WEIM_ADDR_CONFIG_CS0WCR1 (0x83FD8000 + 0x2010)
#define WEIM_ADDR_CONFIG_CS0WCR2 (0x83FD8000 + 0x2014)
#define WEIM_ADDR_CONFIG_REGSITER (0x83FD8000 + 0x2090)

For the IOMUXC_SW_PAD_CTL_PAD_EIM_BCLK, the configured setting is:

Pull/Keeper enabled
Drive strength HIGH.
Fast slew rate.

From the reference manual, EIM_BCLK pad on the iMX51 is not multiplexed

For the transfer I am using memcpy function:

Below is the captured waveform

The BCLK signal should appear as a 66MHZ square clock signal ideally. I am using an oscilloscope that has 400 Mhz bandwidth and using a DC 1MOhm coupling.

Re: IMX51 Synchronous mode issue

igorpadykov — Thu, 01 Feb 2018 23:42:10 GMT

Hi Deepak

"BCLK pad appears tristated " due to oscilloscope probe,

please try to get probe with more high impedance or (using existing)

decrease EIM frequency down for example to 10MHz and check

difference.

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: IMX51 Synchronous mode issue

DeepakKukreja — Fri, 02 Feb 2018 10:18:34 GMT

Ok, but why does the BCLK appear tristated when there is no transaction going on?

Is BCLK an open drain/collector type output that requires an external pull up?

Re: IMX51 Synchronous mode issue

igorpadykov — Fri, 02 Feb 2018 23:17:47 GMT

because lowimpedance/highcapacitance probe acts as rc filtering circuit

for high frequencies and you see average signal on oscilloscope.

Please try with more quality probe.

Re: IMX51 Synchronous mode issue

DeepakKukreja — Mon, 05 Feb 2018 09:56:22 GMT

Thanks Igor,

I could get to the root cause, it was because of averaging applied to the DSO channel because of which I was not able to see the Clock signal properly, I am able to see it now at 66 MHz.

Thanks a lot for your suggestions and help.

Regards

Deepak