Does the SD-library switch chip-select to HIGH after each operation?

Hi,

I tried to read through the SD-library and the underlying libraries trying to find that line of code that shows

digitalWrite(Chip_select_Pin,HIGH)

apparently it seems that switching the Chip-select-pin is done by another command.
I'm asking this because user aattig has problems to get an thermocouple SPI-multiplexer working together with an SD-card which both use SPI

chip-select is active low.
So my question is should any SPI-code switching chip-select to HIGH if it has ended communication?

And is the SD-library doing so? or do I have to execute certain operations to make the SD-library switch chip-select HIGH?

best regards Stefan

If you like to see how SD card access on an Arduino Nano 33 BLE looks like have a look into the following post:

I would recommend to not use SPI for anything else when using a SD card. The SD library is busy in the background for long amounts of time without releasing CS.

Does aattig use a device with multiple SPI peripherals?

no. IMHO the SD lib releases CS after usage.

Several days ago I played around with SD and Ethernet. All my struggles with "failing SD" where not related to the CS handling - adding manual digitalWrites didn't help at all. All the problems come from low remaining memory. Even if I thought theres "plenty" SRAM left. Finally the sketch worked also with a pretty large file readed from SD and forwarded to ETHERNET - a file large enough never to fit in UNOs SRAM - so I'm pretty confident that CS handling of SD (and Ethernet) - works fine. Have you formated the SD card as adviced in https://forum.arduino.cc/t/dont-format-sd-cards-with-os-utilities/222016/48

What are you using to interface the SD card to the arduino? Some of the common SD card adapter boards have a design error where the MISO line is not properly released when CS is released.

hm so what Klaus_K is saying is very different from what noiasca is saying.

So maybe some additional experiments should be done to determine when the SD-lib really releases the ChipSelect-signal.

SD-Card is pretty common. Does somebody know of other threads where a similar problem occured?

SD-Card and an ADG608 analog multiplexer
here is the thread

I'm not familiar with SPI would using a software-SPI for the multiplexer an option?
best regards Stefan

I don't know. My question here was invoked by the thread of user aattig.
Would this problems occur as soon as the SD-card-socket is attached elcetrically to the Arduino without software-initialising the SD-Card?

If yes this is not the case. If the software-initialisation of the SD-card is out-commented reading the SPI-bus for the analog-multiplexer is possible.

best regards Stefan

The user in that thread was using an Adafruit shield for the SD card, which does release MiSO properly.

That thread at one point discusses the possibility that the problem was caused by reading the multiplexer shield using an interrupt, which potentially would occur while the SD card was being accessed. which almost certainly occurs while the SD card is being accessed because the interrupt is being triggered by timer0 and would occur at 1.024mS intervals on an UNO.

imho is soft SPI no solution to the unknown problem. Find the root cause.

Ideas (ordered top down)

a) usage of pins / which bus member is using what pin
b) running out of SRAM. When I'm right, each open SD file will need 512 SRAM - which will not be seen in your globals as it is done after file open(?). Therefore - don't waist memory on large buffers (indeed this was my former issue), use c-strings instead of Strings, ... leave as much SRAM as possible. The SD card might start misbehaving before it really crashes.
c) check the used libraries ... (to be honest, I don't believe that SD.h is your problem)

I'll check if I can add a third SPI component to my test UNO, but I'm pretty confident it will work if it doesn't need to much SRAM.

edit:
I've added to my SD Logger, NTP + Webserver sketch two MAX7219 (daisy chained, using CS pin 8) with 14 segment digits,
and all 3 HW(!) SPI modules are working like planned.

nearly all resources are needed:

Sketch uses 30972 bytes (96%) of program storage space. Maximum is 32256 bytes.
Global variables use 1471 bytes (71%) of dynamic memory, leaving 577 bytes for local variables. Maximum is 2048 bytes.

again, remember the SD Card will need a lot of SRAM when the file is open...