- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Is the first time I work with this SNOR, I think I send the correct SPI stream, but I have no data response from the memory yet.
The SNOR full model identification is: Cypress S25FL128SAGMFB013
Details on how it is currently configured and tested the SNOR:
- Single Data Rate (SDR)
- Mode 0: Clock Polarity (CPOL) = 0 and Clock Phase (CPHA) = 0
- WP# / IO2 and HOLD# / IO3 and RESET# are left unconnected.
- The SCLK operation frequency is: 25 KHz approximately.
- The command that is currently tested is:
RDID = Read ID (JEDEC Manufacturer ID and JEDEC CFI) = 0x9F
- The instruction bits are shifted into the device with the Most Significant Bits (MSB) first.
- The time difference between the falling of CS# and the first CLK clock rising is 20 microseconds meets and exceeds the requirement:
t_TCSS=10 nanoseconds = CS# Active Setup Time (relative to SCK). This is the limit for the part type we are using: Single Die Package.
- In the test setup there are at least 64 clock bits during the time the CS# is held low.
Here are the signals measured with an oscilloscope:
What do you think could be wrong in my SPI setup/sequence that is causing no response from the memory?
Solved! Go to Solution.
- Labels:
-
Serial NOR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sorry for the delay, here are the answers:
1.How many devices are showing this behavior?
One device.
2.Are you facing this issue with all of the devices that you tested?
No.
3.Where did you probe to capture these waveform?
I measured these signals on the flash device pins.
4.Did you probe on the flash device pins?
Yes, I probed on the direct flash device pins.
5.Can you provide schematic diagram of you application? We can review it and check if there are any problem with it.
Unfortunately, at this moment I’m not authorized to do that.
Some very good news is that after testing on a brand-new unit the same software this specific issue is not present because the SNOR responded to the same command.
I believe the first defective tested unit could be damaged. At this moment we don’t need to root cause why the first unit with its SNOR did not work.
You can close this specific question thread with solved status if you wish.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
How many devices are showing this behavior? Are you facing this issue with all of the devices that you tested?
Where did you probe to capture these waveform? Did you probe on the flash device pins?
Can you provide schematic diagram of you application? We can review it and check if there are any problem with it.
Thanks and Regards,
Sudheesh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sorry for the delay, here are the answers:
1.How many devices are showing this behavior?
One device.
2.Are you facing this issue with all of the devices that you tested?
No.
3.Where did you probe to capture these waveform?
I measured these signals on the flash device pins.
4.Did you probe on the flash device pins?
Yes, I probed on the direct flash device pins.
5.Can you provide schematic diagram of you application? We can review it and check if there are any problem with it.
Unfortunately, at this moment I’m not authorized to do that.
Some very good news is that after testing on a brand-new unit the same software this specific issue is not present because the SNOR responded to the same command.
I believe the first defective tested unit could be damaged. At this moment we don’t need to root cause why the first unit with its SNOR did not work.
You can close this specific question thread with solved status if you wish.