Just to make sure I'm completely clear, you are using the SPI communication interface to talk to an external memory, correct?
Also, what version of PSoC Creator are you using?
I also see a similar problem.
In my case I have the following conditions CPU clock 48MHz. SPI clock 400KHz and SPI Master in Mode 00. Reads return data with a 1 bit shift so 5 is actually returned as 2. I can see on the scope that the data is correct. If I slow the CPU clock to 24MHz but keep the SPI clock at 400KHz everythings is fine.
I'm use Psoc3 ES3 silicon with Beta5 creator
My read function is as follows :
unsigned char IF_ReadRxData(void)
while ((SPI_GetTxBufferSize()!=0)); // Wait for Tx FIFO empty ( incase any transfers are left)
while(!(SPI_ReadTxStatus() & 0x10 )); // SPI idle, becuase FIFO can be empty but not idle
SPI_ClearRxBuffer(); // Clear old data
SPI_WriteTxData(0xFF); // Send Data to trigger the transfer
while(SPI_GetRxBufferSize() ==0 ); // Wait for data to come in.
return SPI_ReadRxData(); // Return Data
Also waiting for SPI idle is very slow. What is the best way to do the above. If you can't be sure the previous transfer has finshed before trying to read the next byte.
Instead of using "while(SPI_GetRxBufferSize() ==0 ); " to ensure that the dummy byte has been transmitted, can you try using "while(!(SPIM_1_ReadTxStatus() & SPIM_1_STS_SPI_DONE));" ?
Let us know if you can observe any improvement.
From the description you have provided, it is clear that the received value is right-shifted by 1 bit.
You need to open the configuration tab of MISO input and unsynchronize it by unchecking the "Input Synchronized" from the "Input" tab. This should be able to solve the issue.
Let us know if this works.
I have a problem using too the FRAM FM25V05. I send a quantity of 0b0001000 in the memory ( or 0x10) and when we want to read it we have several errors. In my case, instead of receiving 0x01 we receive 0x00 ...
I use 16MHz CPU with 4MHz SPI clock.
Here a screenshot of my scope showing my problem: (1 = SPI clock, 2 = a trigger that shows where we have a 'read error')
The trigger (channel 2) on this attached picture should fall on a falling edge of the clock, in this case it falls before one half period (average) of the falling edge of the SPI clock.
Have someone any idea about our problem ? What can be the origin of this reading error ?
PS: The writing process succesfull, we have only problem on reading ..
Just something that i have to add, channel 2 is the data that we get from the FRAM. We should get the rising edge of the data from the falling edge of the clock till the next falling edge of the clock, here the "1" falls before the next falling edge ... that is our problem.
if someone have an idea, let me know :)
Deducting from your last description: the data-pulse from the fram is not long enough. Are there any parameters for your memory that can be set differently?
And Are you using the right Mode for the SPI Master?
According to the data sheet, you are using SPI mode 0 (CPOL=0, CPHA=0). This means the data should be set at the falling flank of the clock (which it does) and be read with the rising flank. This is where it fails. The frequency is OK, the FRAM can go up to 40MHz. But did you try with a lower frequency? Do other read operations fail too (e.g. the device ID)?
What looks suspicious to me is the high swing on the data line. Could it be that you don't have a proper blocking capacitor for the FRAM? Or maybe the signal lines are too long
@Bob Marlowe: Hi Bob, thanks for your reply. We are using Mode 0 SPI Clock and about the memory's parameters all is ok.
@hli: You are right about our problem, that data falls before the falling edge of our clock. At higher frequencies we have same/similar errors (@8MHz SPI Clock, @16MHz ...).
What do you mean by writing "Could it be that you don't have a proper blocking capacitor for the FRAM" ?
About signal wires they are shorter as possible.
Thanks for your help.
You should have a 100nF capacitor between Vcc and GND on your chip. Make it as close to the cip as possible. It avoids drops in the power supply when the power consumtion of the chip changes (which happens everytime it starts to work).
This capacitor is solder very close to the FRAM for sure :)
I tought you were speaking about an another capacitor somewhere to put ...
Any other idea ?
But this capacitor is necessary to prevent possible low dropout from Vcc, what is the link between this capacitor linked to vcc and problem with datas readen ?
Not having this capacitor usually leads to erratic behavior - that's why it might have been the reason (e.g. an untimely voltage drop due to some internal triggers firing when the clock signal changes and boom there goes your data line back to zero...). But since this is OK, you might ask Ramtron for more help - this doesn't seem to be an issue with the PSoC.
Am trying to read M25P16 flash interfaced with PSoC3 via spi.
I sent a command byte(0x9F) to read status register,but couldnt get any data back from slave device(M25P16).
PSoC3 is SPI master,i observed in scope that after sending read command,clock was not generated.
SPI clock is 1Mhz,Mode 0 we are operating,CS line drived through firmware. In Screen shot yellow line is CS,
small portion of clock generated was during command write byte,after that during read cycles no data and no clock.
Please let me know your thoughts on this.
Photo 2299.jpg 221.4 K