- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- read status register 0x5
- set write enable latch 0x6
- read status register 0x5 again to see if WEL was set or not
CY15B104Q accepting 32 bit transfer for WEL:
CY15X108QI not accepting 32 bit transfer for WEL:
Is it, should it be possible? It worked in the past for other chip? Please advice.
Solved! Go to Solution.
- Labels:
-
Memory F-RAM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you. When we are allowed back in the lab I will try on a second device. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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