Go Down

Topic: SD card conflict when Servo library embedded (Read 409 times) previous topic - next topic


Hi everyone,
I am having troubles with one of my projects:

I am reading a DHT22 temperature sensor (pin A0, tried D8 also) with a Nano every 5 minutes and save the data on SD card (pins 10 as CS, 11, 12, 13). Once I connect a servo to the project the SD card does not save any data anymore, but the servo works fine as expected.

- Once I exclude the <servo.h> library the sd card works fine again!?
- SD card module uses the 3V3 line of the Nano and has a 220uF electrolytic + 100nF ceramic capacitor to stabilize the power, even though the
- Servo has a different 5V power supply plus a 100nF ceramic capacitor
- Servo is even rarely controlled and never moved when sd card saves data,
- Even if the servo is not connected, just the library is embedded in the code: no data savings!?
- I tried to use another servo library <ServoTimer2.h> if there is any software conflict of both libraries: same result, no data is saved anymore!

I've searched for any solution on the forum, however those discussed problems deal with abnormal behaviour of the servos - nothing about not being able to save data on sd card anymore. Links just for reference:

How is this possible as both work separately, but not if the servo library is embedded in the sketch? Anyone with a similar problem or ideas why this could be?
Thank you!


I'm going to take a wild, unsubstantiated guess that it's something to do with pin 10.

Try a different pin for the SD card's CS, just make pin 10 an output so the Arduino doesn't accidentally become an SPI slave. (Unless the SD card is on a shield....)

Also, if you post your code, I can test it: I have an SD card on breadboard to a Uno right here and I know exactly where (surprise surprise) my test micro servo is.


As the sketch is on the second computer which I reinstall right now I was hoping not to read this... and it will take a few more hours. haha

But anyway: it is a sd card shield with a fiexed pin10. Should be problematic to change that. And even if so: what does the servo or servo library has to do with pin 10???


Ok for what it's worth, I took the sketch File > Example > SD > Datalogger and changed it to use pin 10, added a servo, generated a random servo position, moved the servo, and added the servo position to the string the original sketch writes to the SD card, and all worked ok.

Below is 5 lines of the file as read after moving the SD card to the PC:

Code: [Select]


First 3 fields are analogRead()s of A0-2 as in the original sketch, 4th field is a counter I added, 5th is servo position.

All above on an Uno with external 5V powering the SD module (not a shield) and the servo. I don't have a DHT22.


Thank you for checking, I really appreciat it!
I am having difficulties with the installation process of my other computer (I think the hard disk has faulty sectors), but I will give my project another try today. Did you use the standard servo.h library that comes with the IDE or the ServoTimer2.h library? And without using any capacitor for the sd card?


Standard servo and SPI / SD libraries, no capacitors


I just found out that my LM1117 voltage regulator (as a seperate 5V supply for the servo) is broken/malfunctioning. Knowing that a servo should have its own power source I connected the tiny sevo to VCC of the Nano - the 3V3 sd card with its own connection doesn't save data as expected. So I disconnected the servo, however the library is still embedded in the code and guess what? Still no data is saved!? What is going on here... Isn't is a proof that there has to be some kind of software conflict? I am also using the standard servo and sd card library, I do remember that.

Could there be any chance that my IDE, before formatting the system, had some errors without mentioning these while uploading to the board?


After having switched the Nano I finally found out that the microprocessor wasn't working properly. I don't want to know how many hours I was trying this and that... however it works now and I am glad that I didn't give up!

Thank you arduin_ologist for your mentionable help.


After having switched the Nano I finally found out that the microprocessor wasn't working properly
I hope you smashed it with a hammer so you don't accidentally use it one day and think it's a good one ;)

Go Up