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

[StefanL38]

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

Writing Data to SDCard with Multplex Shield

Thanks StefanL38.....thats would be a good check. I'll take a look at it later this evening. I did find a blog related to this on adafruit that talks about manipulating the mux on/off and coordinate the sensor reading with writing to the SD Card. This blog kind of made sense, but again not sure how to implement/test in my code at the moment... https://forums.adafruit.com/viewtopic.php?f=31&t=39699

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

[Klaus_K]

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

BLE 33: Writing to SD Card (SPI) stuck every 15ms

During the 15ms the data is actually written to the SD card. I did an experiment with your sketch and a logic analyzer and looked at the SD card signals plus a debug signal. Have a look at the screenshot. The debug line goes LOW before the myFile.println( millis() ); and HIGH after the call. [Nano 33 BLE SDcard.png] As you can see there is a burst of calls (~70) and then one call takes ~16ms and then there is another burst of calls. [Nano 33 BLE SDcard.png]

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?

[noiasca]

@StefanL38

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

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 [url]https://forum.arduino.cc/t/dont-format-sd-cards-with-os-utilities/222016/48[/url]

[david_2018]

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.

[StefanL38]

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?

@Klaus_K

Does aattig use a device with multiple SPI peripherals?

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

Writing Data to SDCard with Multplex Shield

Hello, I'm working on a project utilizing 6, T-type thermocouples for ground temperature measurements over time. My interface is the Ocean Controls Thermocouple Multiplexer Shield (KTA-259T) mounted atop an arduino Metro from Adafruit. The issue is I need to write the thermocouple temperatures to an Adafruit SD Card Shield. I've reviewed some of the sample codes for SD cards and am currently able to get the card to initialize in my sketch and thats the extent. From what I've read, the code ne…

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

[StefanL38]

@david_2018

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.

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

[david_2018]

@StefanL38

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?

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.

[noiasca]

@StefanL38

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

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...