Conflict between RTC and SD on SPI

Status
Not open for further replies.
D

dave@huckleberrycove.ca

Member
I designed a data logger with a Teensy 3.2. It senses a signal on the A/D, and measures acceleration with a SparkFun ADXL435 on I2C. It also has a SF RTC DS3234 and a SF SD card (DEV-13743) on SPI. I built two prototypes and they work correctly. Now I have produced a PCB and find I have a conflict between the RTC and the SD card.

When I built the first version I had a similar conflict and noticed that if I touched the RTC board it would sometimes work. I discovered that a 0.1 uF cap between GND and the RTC CS made it work consistently. But why? The PCB version still has the conflict between the RTC and SD, even with the 0.1 uF.

I wrote a little test sketch which reads the RTC and prints the time 5 times per second.

(When I tried to attach the code, I lost my post and had to type it all again. I will post without the code and then try to send it again.)

When I run my logger without an SD card inserted, it works and I can set and read the time. If I insert an SD card, it does not set the time correctly but it all runs, even writes data to the card. So the wiring must be correct.

The RTC test holds the SD CS high so it should be “off”. When I run the RTC test, it shows the correct time if no SD card is inserted. If I insert a card, the time output becomes totally wrong. If I remove the card, the time is correct again (even without a restart). I make a scope trigger pulse on PIO 4. I have looked at MISO, MOSI and SCLK with and without the card and see no difference.

Any ideas? I do not like to fix things with a random capacitor here or there.

Dave Heffler
 

Attachments

  • RTCTestPCB.ino
    3 KB · Views: 119
Maybe try adding pullup resistors on both CS pins? You could try doing things in software too, but for troubleshooting physically adding 2 resistors is simpler because they will be certain to be "enabled" immediately at powerup. ;)

Edit: if that doesn't solve everything, maybe try posting photos and diagrams of your custom PCB the prototype, showing how you actually connected everything. It might be something simple, but we can't look unless you post pictures.
 
Paul
Thanks for your suggestions. I tried the pullups (10K) on the two CS's. I also added 1 uF caps on the VCC to GND of both boards. Neither helped.

I changed my test code a little. I have the RTC set for the present time. If it doesn't work the year does not get read as 17. So I now flash an LED if it reads 17 for the year and I can tell immediately if it is working or not. When I touch the CS on the RTC (or the SCLK) it works. Sometimes other pins cause it to work.

I can't really say that this is a Teensy problem. The teensy reads the RTC correctly and can read and write to the SD card. So they both must be wired correctly and programmed correctly. The only problem is reading the RTC if an SD card is installed. The Spark Fun SD card board is just a breakout for the SD socket. There is no circuitry on the board. I can scope the signals (SCLK, MISO, MOSI and CS's and VCC and GND) and there is no change when I plug in the SD card (except for the data coming out of the MISO).
I tired running extra gnd and VCC wire to the RTC and also tied the SD CS high on the board. I also removed the trace to the RTC SCLK. Nothing helped.

Now I notice that pins 7,8 and 9 are shown as an extra SPI port. Might it be possible to use one SPI for the SD and different one for the RTC? But I don;t know how to use the other SPI. In my RTCInit function, it just does an SPI.begin(). I don't see anything to tell it which SPI pins to use.

Dave Heffler
 
Paul
Since my last post, I browsed your site a little and it appears that there is only one SPI device, it just has alternate pins. But I only read my RTC on power up, before I use the SD card and it is not speed critical. So maybe I could bit bang the RTC and just use the built in SPI for the SC card. In ancient times, I have written lots of bit bang UARTs and SPI code. I was hoping that modern microprocessors would eliminate the need to do any more. But it will be faster for me to do that than to carry on trying to solve my existing problem. (Although I would like to know a good solution.) Do you know of any Teensy SPI bit bang code that already exists?

Dave Heffler
 
I made a bit bang version of SPI. It reads and writes the RTC without using the built in SPI. But now SPI.begin() doesn't work. It returns false. I need it for the SPI control of the SD card. Do I need a working SPI device connected for begin() to work? How do I find the source code for SPI.begin (using arduino)?
 
The only problem is reading the RTC if an SD card is installed.
Click to expand...

dave, there is a well-known problem with trying to use SD cards on the same SPI buss with anything else. The problem is SD does not release the MISO pin properly after CS is de-asserted. You can check this. If you're using one of those SD card holders with an interface chip rather than series-Rs the pin totally locked from release.

Supposedly if you send a series of Sclk pulses *AFTER* de-asserting CS, then the SD card will release the MISO pin, but the interface chip, if present, will still hold the pin from changing.
 
Thanks oric_dan for those ideas. ... well known by whom?
At any rate, I have put the RTC on a bit banged SPI since I don't use it when anything else is happening. That works and the SD card can hog the SPI interface.

I must push on with the project so I will consider this thread closed. But if I ever revisit the issue, I will try the extra SCLK pulses.
 
"well-known" - maybe not the best choice of terms, :).

When this was going around a couple of years ago on the arduino forum, Bill Greiman said he had implemented the extra Sclk pulses into the SdFat library - but that fix apparently did not work for you. I would suspect your SD card holder module has the interface chip rather than the series-Rs, and is holding the MISO pin from changing, as mentioned previously.

EDIT: FWIW, on arduino boards, I have had upwards to 5 devices "successfully" sharing 1 SPI port, ethernet, RFM radio, SPI LCD, &etc, but not with SD included.

Another thing, the T3.1,3.2 have the FIFO-equipped SPI port, and that is a dog to try and share SPI devices. That's why Paul added the SPI-transaction stuff, but I never had much luck with it - and I tried. So, I ended up going to Teensy LC and 3.5,3.6 for every app where I have used multiple SPI devices.
 
Last edited:
If I remember correctly, the Teensy has an internal RTC which can be enabled by adding a crystal and a battery. Why not use this one which doesn't need the SPI bus?
 
Theremingenieur said:
If I remember correctly, the Teensy has an internal RTC which can be enabled by adding a crystal and a battery. Why not use this one which doesn't need the SPI bus?
Click to expand...

Here is the library documentation for the real time clock:

Note, the Teensy LC does not have a real time clock. The Teensy 3.0, 3.1, and 3.2 need an external 32.768 kHz crystal. The Teensy 3.5 and 3.6 do not need an external crystal.

The Teensy's RTC is not temperature corrected like the DS3231's. I recall there was discussion in the old days about using the internal Teensy temperature sensor (pin 38 on the LC/3.0/3.1/3.2 or pin 44 on 3.5/3.6) to correct the Teensy's RTC drift:
 
Status
Not open for further replies.
Back
Top