CY15B102Q does respond to opcode commands

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

cross mob
RaOr_4729521
Level 1
Level 1

Hi,

I am interested in using this parts for logging data from a tool that we are preparing to test in the field, but I am having difficulty getting any response from the commands that I am sending.  I have tried RDID, RDSR, and a WREN-WRITE-READ operation without success.

I have setup the device on a breadboard interfaced to the SPI port of my microcontroller (CS,SCK,SI,SO), and the WP,HOLD pins on the chip are tied to 3.3V.  Power (3.3V) and Ground are also connected on the chip.  Note: I have tried 3 different chips with no success.

Here is a scope shot of my attempt to read the device ID from the chip.

tek00015.png

Here is a closeup of the opcode byte for the RDID command.

tek00016.png

It appears as if the SO line from the CY15B102Q does not ever come out of its Hi-Z state.

Any input would be welcome,

Thanks

0 Likes
1 Solution

Thanks for the response,

It appears that my test setup was the problem.  I had prototyped the FRAM chip on a breadboard and connected the SPI interface using test leads to a terminal block that was connected to my MCU.  The capacitive load introduced by the cabling and terminal block must have exceeded the drive capability of the SO pin.  Once I rewired the test setup, the problem went away.

Regards,

Raul

View solution in original post

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

Hi,

1) Can you once check if all the connections to the device on the breadboard are as per the operating conditions for the device.

2) Can you provide a common ground for the device and the MCU. The SPI protocol may not respond if the ground potential is different for the MCU and device.

3) You can also try to put more GND connections between MCU and memory device.

Thanks,

Pradipta.

0 Likes

Thanks for the response,

It appears that my test setup was the problem.  I had prototyped the FRAM chip on a breadboard and connected the SPI interface using test leads to a terminal block that was connected to my MCU.  The capacitive load introduced by the cabling and terminal block must have exceeded the drive capability of the SO pin.  Once I rewired the test setup, the problem went away.

Regards,

Raul

0 Likes