WEL code not accepted as part of 4 bytes "command" for CY15X108QI

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Viking
Level 1
Level 1
First reply posted First question asked First like given

For better bus utilization on our system we use 32 bit width, including 32 bit spi transfer. It has the side effect that WEL opcode/command is sent as a 4 byte command which has worked fine in the past, using the FRAM device CY15B104Q. Now that we have changed to FRAM device CY15X108QI it does not work anymore. We have tried to have the WEL opcode first, last or fill all bytes, including having the other bytes as 0s, 1s or 55 which I think was mentioned as idle pattern, nothing makes the WEL latch when using 32 bit transfer. Sending the WEL opcode as a single byte works as expected, but is not how we would preferably do this.

The attached data is captured for the two devices using digital analyzer, and show

  1. read status register 0x5
  2. set write enable latch 0x6
  3. read status register 0x5 again to see if WEL was set or not

CY15B104Q accepting 32 bit transfer for WEL:

 

CY15B104Q_workingCY15B104Q_working

CY15X108QI not accepting 32 bit transfer for WEL:CY15X108QI _not_workingCY15X108QI _not_working

Is it, should it be possible? It worked in the past for other chip? Please advice.

0 Likes
1 Solution
GirijaC
Moderator
Moderator
Moderator
50 sign-ins 25 sign-ins 10 solutions authored

Hi,

F-RAM CY15B108QI product implement the opcode logic according to the data sheet description. All opcode only commands such as WREN are expected to receive only one byte. If the host tries to send more than a byte, the device internally disregards the command.

Their is no workaround to send 32 bit Instruction in CY15B108QI for WREN command.

Thanks,

Girija

View solution in original post

0 Likes
5 Replies
PradiptaB_11
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi,

Using 32 bit width should be possible. Can you let us know the frequency at which you were testing this. Also can you let us know how many devices have you tested ?

Thanks,

Pradipta.

That is very interesting!

It was running on 6.25 MHz when we did the data capture, now we use 18.75 Mhz. It is the WEL command we can’t make work for 32 bit command, that write latch/bit is then not set. So now we have a custom SPI controller that allows dynamic switching between 32 and 8 bit commands so WEL has 8 bit and read/write 32 bit, it works but add quite a bit of controller and driver complexity.

How should a 32 bit WEL command be designed? What byte should contain the WEL opcode 0x6, and what should be used for the padded bytes?

It may have been tested on a single device only, with later devices only using the workaround dscribed above.

Appreciate your time!

0 Likes
PradiptaB_11
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 replies posted

Hi,

Since the SPI protocol used is same on both the FRAM chips that you have used the command you provide to the older FRAM device should work on the newer one as well. Your method is correct actually, when CS pin is asserted we need to send a valid opcode first like the WREN opcode 0x06 and then you can pad the other bytes as you done in the previous scope shot. Kindly allow me some time to check on this with my team internally to debug this and come back to you.

Thanks,

Pradipta.

Thank you. When we are allowed back in the lab I will try on a second device. Thanks.

0 Likes
GirijaC
Moderator
Moderator
Moderator
50 sign-ins 25 sign-ins 10 solutions authored

Hi,

F-RAM CY15B108QI product implement the opcode logic according to the data sheet description. All opcode only commands such as WREN are expected to receive only one byte. If the host tries to send more than a byte, the device internally disregards the command.

Their is no workaround to send 32 bit Instruction in CY15B108QI for WREN command.

Thanks,

Girija

0 Likes