- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The overzeralous spam filter here is being a real pain...
Had to chunk up my post until I figured out what the offending parts were, then attach my example code as images because I couldn't post it.
Sorry about the mess here.
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I'm attempting to read and write from an EEPROM chip (Microchip 25AA02E40) via an SPI_Master componenet. I've referenced the chip's datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/20002123E.pdf) and an excample project I found (http://www.cypress.com/knowledge-base-article/interfacing-psoc1-spi-eeprom) and it's largely working, but the end result in inconsistent.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm using PSoC Creator 3.3 and PSoC 5 chips.
~95% of my reads and writes work, but about 5% would fail, either not writing the new value and leaving the old in memory, or not reading a value and instead reading 0x00. Oddly, removing waiting loops after each word made it more consistently work, rather than fail more.
I'm using an SPIM component with a High Impedance Digital MISO and three Strong Drive pins for MOSI, signalClock, and SS (select).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And here is my write function:
...
When I add the while looks back to the read it makes it much more error prone.
Also, I attempted to add a call to the read function to the end of the write function to verify the value written was written but it fails much more consistently that in it's separate function. For now I've brute forced it such that write retries until a read matches, and read reads 3 times and waits until they all match. But this isn't ideal.
I tried replacinmg the SPIM_EEPROM_STS_TX_FIFO_EMPTY with SPIM_EEPROM_STS_DONE or SPIM_EEPROM_STS_IDLE but both just lock up the firmware, and appear to loop forever.
Any idea what I might be missing? I though SPI should be pretty robust and straightforward, easy to get consistent results.
Sean
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apparently the sample code I have for my read and write functions aren't allowed to be posted with the spam filter rules. Here's the read function
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sean
Is it possible that some times the CS does not go high after you send "write_enable" ?
This would explain why the write some times is not working. Do you have a scope or logic analyzer to check how it works?
The other question is if you made sure not to write more than 16 bytes in a row?
All the Best
Frank
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think your busy-flag check is not OK. You write two values to the SPI (which is correct). But the you check for the RX FIFO for not being empty, and the read the results. This might lead to the situation that you read after only one byte is in the RX FIFO, which you would then treat as a the status register value. This one is probably 0x00 every time, which would indicate that the write is finished.
Wait to have exactly two bytes in the RX buffer, and then read the second one.