IMX51 Synchronous mode issue

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX51 Synchronous mode issue

863 Views
DeepakKukreja
Contributor III

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

pastedImage_22.png

For the transfer I am using memcpy function:

Below is the captured waveform

WEIM Sync wwsc 8 bcd 1.png

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.

Labels (2)
0 Kudos
4 Replies

598 Views
igorpadykov
NXP Employee
NXP Employee

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!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

598 Views
DeepakKukreja
Contributor III

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?

0 Kudos

598 Views
igorpadykov
NXP Employee
NXP Employee

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.

0 Kudos

598 Views
DeepakKukreja
Contributor III

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

0 Kudos