Trouble sharing SPI pins with SD Card and another device using fsrw26
dbpage
Posts: 217
I have been using fsrw26 for many years without issue. I often use multiple instance of fsrw26 to work with multiple files without issue.
I am currently working with a hardware design that shares SPI pins with another device. My goal is to read data from an SD card and, using the same SPI pins, to transmit the data to another device. The SD card and other device share CLK, MISO, MOSI pins, and each have their own dedicated CS pins. The pins have pull up resistors.
It appears to me that when fsrw26 mounts the SD card, opens a file and reads a byte, fsrw26 does not release the SD Card CS pin; the pin remains actively driven low.
There are PASM lines in safe_SPI that read:
Uncommenting this line does not resolve the issue.
Is there a magic bullet that you can share to accomplish my goal?
Edit: Uploaded a schematic diagram
I am currently working with a hardware design that shares SPI pins with another device. My goal is to read data from an SD card and, using the same SPI pins, to transmit the data to another device. The SD card and other device share CLK, MISO, MOSI pins, and each have their own dedicated CS pins. The pins have pull up resistors.
It appears to me that when fsrw26 mounts the SD card, opens a file and reads a byte, fsrw26 does not release the SD Card CS pin; the pin remains actively driven low.
There are PASM lines in safe_SPI that read:
' if you are using pull-up resistors, and need all ' lines tristated, then uncomment the following line. ' for Cluso99 ' mov dira,#0
Uncommenting this line does not resolve the issue.
Is there a magic bullet that you can share to accomplish my goal?
Edit: Uploaded a schematic diagram
Comments
If you are using multiple instances of fsrw then that means they are running in multiple cogs which means that if any cog leaves an output high then another cog will not be able to take it low since outputs are OR'd.
However in this case it may simply be that the SD card itself still has data out active even though the CS line has been deactivated. I normally run a few more clocks after access before de-asserting CS. The other thing that can happen is that I've seen certain non-Sandisk cards output clock pulses onto the DI line at power-up, totally non-standard.Try using a genuine (non-ebay) Sandisk card.
BTW, my Tachyon file-system normally supports up to four open files and the only reason I don't normally support more is because I have better uses for all that memory.
I don't rely on the SD Card having pullup resistors. I use cards branded by Parallax or MicroCenter. The customer may substitute brand X. I recall fsrw26 running a few extra clocks. I'll look to see when.
I conducted additional tests. The SD Card CS pin remains actively driven low after mounting the SD Card. The SD Card CS pin floats after unmounting the SD card. This is true if I comment or uncomment mov dira,#0.