SD only partially works.

I don’t know if this is just me, but SD seems really flakey

The cardinfo demo seems really reliable, but the other demo’s that read and write files seem pretty hit and miss.

I’m not sure if this is because the default speed for the SD Lib is HALF speed. But on STM32 that HALF speed on SPI may be too fast for some SD Cards, especially the cheap ones.

Has anyone else experienced problems reading and writing files to SD ?

As I can remember, the SD lib runs very fine to me. But(!!) not with all adapters! Some TFT build in SD-adapters didn’t work properly. I also found out that some SD-card adapters work better with specific MCU’s (PIC32, Tiva-TM4c123, STM32) and some do not. Sounds a little bit esoteric, but I didn’t have time why. So maybe use the same configuration with a other adapter first?

Thanks Matthias

I think I can now make it work with one of my micro sd cards, but I can’t seem to make it work with a full size SD card (though a different adaptor)

It doesn’t seem to work with larger micro SD cards. I have a 4Gb , SanDisk branded HC card , which doesn’t work.

I have not researched this yet, but I have a feeling HC cards may not work.
I thought FAT was ok up to 4Gb so should work, but perhaps that’s wrong.

Two of my boards ( the F103VET and F103ZET) have an SD adaptor on the back of the board, but I don’t know what it’s connected to.
I suspect that as both processors support SDIO that its connected that way, rather than to SPI but I will need to use a continuity tester to try to work out how it’s connected.

On my side, I still gtruggling to make SdFat/SPI working on my Netduino2Plus F405.
It is aborting almost right at the begining. Here are some trace I’ve enabled or added :
before sd.cardBegin !
SdSpiCard::begin / spiBegin() !
SPI configure_gpios / (nss=16, sck=42, miso=43, mosi=44)
spi_master_enable(48,0,768)
SdSpiCard::begin / spiInit() !
Bit order set to 1
SPI configure_gpios / (nss=16, sck=42, miso=43, mosi=44)
spi_master_enable(48,0,768)
Data mode set to 0
SPI configure_gpios / (nss=16, sck=42, miso=43, mosi=44)
spi_master_enable(48,0,768)
Clock divider set to 48
SPI configure_gpios / (nss=16, sck=42, miso=43, mosi=44)
spi_master_enable(48,0,768)
SdSpiCard::begin / 74clock spiSend() !
SdSpiCard::begin / cardCommand(CMD0) !
SdSpiCard::begin SD_CARD_ERROR_CMD0 !
SdSpiCard::begin FAIL !
SDCard initialization failed !


Martin

Do you mean the SD lib is calling begin all other the place ?

I presume you are using the SD lib that’s part of the IDE like I am ?

I know victor has a revised / improved SDFat lib on his GitHub account, but Im not sure if it replaces SD or is a utility that SD uses

PS. I wonder how well SD a actually works on AVR, I suspect its just as flakey and depends on which adaptor and card you are using

Hi Roger,

RogerClark wrote:Do you mean the SD lib is calling begin all other the place ?

Martin

I suspect the Begin is being called because the hardware doesnt allow some things like the bitOrder or the clock divider to be changed when the SPI port is enabled (I remember you definitely can’t switch from 8 to 16 bit transfers when the SPI hardware is enabled)

It was probably me that put the calls into begin() into the code, but the alternative may just be to call

spi_master_enable(spi_d, (spi_baud_rate)clockDivider, (spi_mode)dataMode, flags);

plus the other code, but unless you can cut some of the code out, it almost seems logical to call begin() every time you change the settings

Albeit perhaps you don’t need to call configure GPIO

So I suspect a better approach would be to write a function called setSPISettings() which is called after you change bitOrder etc and also called from begin()

RogerClark wrote:
I know victor has a revised / improved SDFat lib on his GitHub account, but Im not sure if it replaces SD or is a utility that SD uses

I’ve tried Victors updated version of SdFat but it doesn’t seem to work at all for me

The card won’t initialize.

So I”ve gone back to using the standard SD that is part of the IDE install.

However its ultra flakey

I know this is old news… But the SD lib seems to fail to read for no apparent reason, e.g. i call dataFile.read(buff,LEN); and it just returns -1 at random, which means its failed, and if you try to read again without leaving a long time delay e.g. 10ms it just keeps returning -1

Anyway, in terms of what I was trying to do, I’ve got something that sort of works, but isn’t reliable enough to be used.

It opens and reads a file from SD and plays it as an MP3 though a VS1003

I will repost the code to the VS1003 lib thread in case anyone with the same hardware wants to have a play with it

#include <VS1003_STM.h>
#include <SPI.h>
#include <SD.h>

VS1003 player(PC14, PB10, PA8, PA9, SPIClass(2)); // cs_pin, dcs_pin, dreq_pin, reset_pin

/*
* VS1003 development board connected by it's header pins the following way:
*
* GND - GND -
* XDCS - D6 - PB10
* DREQ - D7 - PA8
* XRES - D8 - PA9
* XCS - D9 - PC14
* SCLK - D13 - PA5
* SI - D11 - PA7
* SO - D12 - PA6
* GND - GND -
* 5V - 5V -
*/

void setup ()
{
Serial.begin(115200);

// while (!Serial.available());/// Wait for key entry.. For debugging

// see if the card is present and can be initialized:
while (!SD.begin(PA4))
{
Serial.println("Card failed, or not present");// don't do anything more:
delay(100);
}
Serial.println("card initialized.");

player.begin();
player.modeSwitch(); //Change mode from MIDI to MP3 decoding (Vassilis Serasidis).
player.setVolume(64);
}

int currentFileNum = 0; // Hack because SD only allows one file handle open at a time :-(
void loop()
{
playFile("music.mp3");// Lets just play the music ;-)

delay(1000);
return;
}

#define BUFF_LEN 128

void playFile(char *fileName)
{
uint8_t buff[BUFF_LEN];
File dataFile;
int bytesRead;
int fileSize;
int totalBytesRead = 0;

dataFile = SD.open(fileName);

if (!dataFile)
{
Serial.println("Error opening file");
return;
}

Serial.print("Playing "); Serial.println(fileName);
fileSize = dataFile.size(); // need to know the size of the file

// loop until end of file
while (totalBytesRead != fileSize)
{
do
{
bytesRead = dataFile.read(buff, BUFF_LEN);// try to read a buffers worth
if (bytesRead == -1) // Oops. SD didnt manage to read anything ....
{
delay(10);// Workaround for problem in SD lib.
}
} while (bytesRead == -1);// loop around if last read failed

player.playChunk(buff, bytesRead);
totalBytesRead += bytesRead;// keep track of how much of the file we've played
}
dataFile.close();
}

RogerClark wrote:I’ve tried Victors updated version of SdFat but it doesn’t seem to work at all for me

The card won’t initialize.

In my case, I’ve tried Victor’s version, and this morning Bill Greiman’s one as well as default Arduino one.
They are all failing during command CMD0, so, I suspect more that my port of SPI from F1 to F4 doesn’t work, although there are not much differences.

pico wrote:
<…>
I’m actually quite surprised by this — not so much the code doesn’t work (even back in the old days the libmaple guys had a hell of a time getting the SD code base to work on a maple for some reason), but the fact that it doesn’t work and Bill Greiman accepted the pull request! In my experience, he’s usually fairly conservative to the point of paranoia…

Given how far things have come with SdFatLib since those days, however, I’d be looking at the Teensy 3.x code as the place to start for a fresh stm32 port — similar speced processors, and I know Bill has put a lot of time into getting it to run right on that platform.

mrburnette wrote:
I cannot speak for Victor, but I have used Paul’s Teensy code in the past, sometimes it is enlightening … sometimes, just not anything but #ifdef’s.

The changes for SdFatLib for Teensy 3.x were all due to Bill, not Paul — as I say, Bill tends to keep it pretty close to his chest when it comes to modifying the SdFatLib source.

Well, I do not really care how they got into the Teensy ecosystem, only that they did! (I am a Teensy3.1 owner) Bill has done a great job over the years and Paul has provided Arduino compatables that are a great value.

But as big-name companies change the Arduino hardware, the SD will look more and more abstract – like a flashcard in a PC.

Personally, I do not subscribe for using the main microprocessor for SD. A second, dedicated microcontroller is a more sensible datalogger. https://www.hackster.io/rayburne/sd-card-serial-logger If the design requires reading, parsing, writting and such: move to an rPi. On an 328 AVR, 512 Bytes are required for buffering write and 512 Bytes are required for read. IMO: just silly to try and mix this requirement with program logic.

As the STM32 bottom line is 20K SRAM, the effort to integrate SD into the main program logic is more tempting.

Ray

Guys

I’ve not had time to test it yet, but it looks like the reason SdFat ( the latest version of SD) didn’t work for me, is that you can’t use PA4 as CS, and accidentally I used that pin as it happens to be next to the other SPI pins on my board which made the wiring easier.

If it works, I will add SdFat as a library, because using the old one supplied with the IDE

it could just be my particular hardware setup that doesn’t work well with the old SD lib, its hard to tell.

BTW. Mysteriously my Sandisk 4Gb micro SD card is started to work with the old SD lib when I was trying to get my MP3 player working yesterday , and my dodgy 2Gb SD stopped working.

Anyway, I will try SdFat again and report back on its stability for me, with a range of different cards.

Anyway, I will try SdFat again and report back on its stability for me, with a range of different cards.

Bill once did this and published his results, but I cannot find the reference at this time. And his work was for the AVR 8-bit, so I do not know if the 32-bit hardware would affect the results beyond speed.

It will be interesting, anyway.

Ray

Hi Ray

I will report back

The frustrating thing, is that SD is just one part of what of a test project (Mp3 player), it wasn’t supposed to be the problem area, the VS1003 was supposed to be the device I was getting to grips with

With the mp3 playback, getting data to the VS1003 in time is critical, as it only has a 5 k internal buffer, and doesn’t transfer that fast ( DIV 16 I think)

Git the SPI for the VS1003 working on SPI2, but as neither the SD or the VS1003 are using DMA it doesn’t give me any performance advantage.

I will look at using DMA for the VS1003, but I think I’d also need to use an interrupt on its DREQ input (data required), in order to kick off a 32 byte DMA block transfer, in order to make the whole thing a bit more multitasking in nature

With the mp3 playback, getting data to the VS1003 in time is critical, as it only has a 5 k internal buffer, and doesn’t transfer that fast ( DIV 16 I think)

Maybe RTOS? Is not that what it is all about…

Ray

Just a quick update, as I think I”m going to put this on hold as I have other STM32 stuff I need to look at…

I’ve tried changing the CS pin, I’ve even tried just pulling the CS pin to GND, and I still cant get the new lib to work with any of my micro SD cards

I’m beginning to wonder if this is a hardware e.g. voltage levels issue

I am using this micro SD adaptor and was running it from 3.3V

However, looking at it, I can see its got a regulator on it.

So on my Red Pill board, I change the input voltage from 3.3 to 5V, and this seems to make my cheap / clone 2 Gb SD card more reliable on my Red Pill – but still doesn’t allow me to use SDFat.

I’ve tried downloading Bill’s repo, but it doesnt compile, as it gets errors because of missing definitions to SPI_DMAC_TX_CH

I don’t get these errors when using Victors version. So it looks like there is something out of sync betweeen Victors last pull request to Bill’s repo, and what victor has updated in the SPI with regards to DMA

I’m not sure if Victor is reading this thread, so I will PM him about this.

Just a quick update.

It looks like the issue with the normal SD lib, is the same as for the new Lib

You can’t use PA4 as Chip select on SPI, because this is the NSS pin (hardware SPI Chip select).

By accident I tried just connecting CS to GND and I noticed that it seemed a lot more reliable, so I tried PA2 instead of PA4 as CS and it seems equally reliable,
I’m no longer getting -1 return from File.read(buff, length), also the card seems to init straight away.

So I think the status of the SD lib, is it does work, but only if you don’t use PA4 for CS

Good found Roger!
I never had such a problem, because I always use a seperate CS pin (and not the HW NSS pin) since the “old Arduino days”, except I completely doing SPI “per hand”. But good to know that this “problem” still exists, even on STM32-duino.
When I have time, I’ll open a thread in the global section and post my results all my SD-cards + adapters in every combination. All I can say is that your adapter on the photo (with the 5V to 3.3V conversation) works on nearly every MCU (even on 3.3V) for me – drawback: mini SD-cards only:/

RogerClark wrote:So I think the status of the SD lib, is it does work, but only if you don’t use PA4 for CS

Now, a bit of googling suggests there may be some inherent weirdness in the F103 silicon re the CSN pin behaviour.

Here’s a quote from a forum post on STM in 2012:

Confirmed here (on the STM3240G-EVAL board), also with setting the NSS on PB9 instead of PB12. The NSS pin stays low. When set to TI mode, it starts toggling, so the GPIO- and AF-setting is correct.In “standard” mode it stays low even if the enable bit (CR1.6) is cleared.

I’d say this is simply a design flaw, covered up partially by the following sentence in the manual:

“Note: When a master is communicating with SPI slaves which need to be de-selected between transmissions, the NSS pin must be configured as GPIO or another GPIO must be used and toggled by software.”

It would be nice to hear some comment from ST.

JW

Here’s a link to the forum page on my.st.com with that post:

https://my.st.com/public/STe2ecommuniti … views=1705

So it looks like even one ST manual is saying the CSN needs manual control from a GPIO other pin than the hardware ports designated CSNs!

Note that even this doesn’t override the weird behaviour:

pinMode(BOARD_SPI2_NSS_PIN, OUTPUT);
:
:
digitalWrite(BOARD_SPI2_NSS_PIN, LOW);
SPI_2.transfer(b);
digitalWrite(BOARD_SPI2_NSS_PIN, HIGH);


….and if the slave is not totally overwhelmed, then comes the “bang” at the latest here:

EDIT: So the best workaround would be to deselect the NSS pin in the SPI library (and using it as normal GPIO) and toogle it per hand or within a wise library addon

madias wrote:EDIT: So the best workaround would be to deselect the NSS pin in the SPI library (and using it as normal GPIO) and toogle it per hand or within a wise library addon

Umm

There is some stuff on page 694 of the manual

Slave select (NSS) pin management
Hardware or software slave select management can be set using the SSM bit in the
SPI_CR1 register.
• Software NSS management (SSM = 1)
The slave select information is driven internally by the value of the SSI bit in the
SPI_CR1 register. The external NSS pin remains free for other application uses.

RogerClark wrote:Umm

There is some stuff on page 694 of the manual

Slave select (NSS) pin management
Hardware or software slave select management can be set using the SSM bit in the
SPI_CR1 register.
• Software NSS management (SSM = 1)
The slave select information is driven internally by the value of the SSI bit in the
SPI_CR1 register. The external NSS pin remains free for other application uses.

Today I found some time to test the default arduino SD library (SD) with my STM32F103CT8.
At the first, It didn’t worked (at least to me). But after a few additional lines to the standard library it worked.

Edit the file Sd2PinMap.h (arduino-1.6.4\libraries\SD\src\utility) and add following lines:

//------------------------------------------------------------------------------
#elif defined(__STM32F1__)
uint8_t const SS_PIN = PA4;
uint8_t const MOSI_PIN = PA7;
uint8_t const MISO_PIN = PA6;
uint8_t const SCK_PIN = PA5;
//------------------------------------------------------------------------------

I just tried changing the flags

by adding SPI_CR1_SSM_BIT

uint32 flags = ((bitOrder == MSBFIRST ? SPI_FRAME_MSB : SPI_FRAME_LSB) | SPI_DFF_8_BIT | SPI_SW_SLAVE | SPI_SOFT_SS | SPI_CR1_SSM_BIT);

Vasillis

We alrready have definitions (placeholders )

#warning these are just here to get SPI to compile they need to be changed and moved!
#define SS (1)
#define MOSI 2
#define MISO 3
#define SCK 4

We need a gpio_get_mode() that does the reverse of

void gpio_set_mode(gpio_dev *dev, uint8 pin, gpio_pin_mode mode) {
gpio_reg_map *regs = dev->regs;
__io uint32 *cr = &regs->CRL + (pin >> 3);
uint32 shift = (pin & 0x7) * 4;
uint32 tmp = *cr;

tmp &= ~(0xF << shift);
tmp |= (mode == GPIO_INPUT_PU ? GPIO_INPUT_PD : mode) << shift;
*cr = tmp;

if (mode == GPIO_INPUT_PD) {
regs->ODR &= ~(1U << pin);
} else if (mode == GPIO_INPUT_PU) {
regs->ODR |= (1U << pin);
}
}

I think there is a pinMap error. It seems that when you define a pin with a plain number (2, 3, 4, etc) the definition wont work.
That’s why I always use the PXX or PXXX syntax when I define a pin.

RogerClark wrote:
Slave select (NSS) pin management
Hardware or software slave select management can be set using the SSM bit in the
SPI_CR1 register.
• Software NSS management (SSM = 1)
The slave select information is driven internally by the value of the SSI bit in the
SPI_CR1 register. The external NSS pin remains free for other application uses.

The manual, RM00008 seems to imply that MSS needs to be set

Software NSS management (SSM = 1)
The slave select information is driven internally by the value of the SSI bit in the
SPI_CR1 register. The external NSS pin remains free for other application uses.

But it’s worth trying the other combinations, as the manual is sometimes wrong

pico wrote:I will experiment.

pico wrote:[…]but there does seem to be some hope that the CSN pins should be able to be toggled manually in gpio mode — which although not ideal, would be better than nothing.

I actually ran into this same problem on AVR using the NSS pin. On the AVR the NSS pin is used to set Master/Slave. So when ever the NSS pin was written low, it was putting SPI into slave mode. Now when I code SPI, I think of the NSS pin being an input to the mPU.

As for an SD library, I use Chan’s FatFS and PetiteFatFS. I think the “Middleware” Code STM32CubeMX includes is the same library as the link will lead to the elmChan site. This code will even run on an AVRtiny45 top play *.WAV files. (Had to hack some of it to do so.) Runs quite well on a AVRTiny85 with room to spare. I did a project which was a toy piano where we made 333 units using a AVRtiny85. The smallest card I could get in bulk was like 4 gigabytes.

I like the idea of using a second data logging processor to handle the SPI read/write to the card. Especially the FAT writes to dynamically allocated files. Reading is not much of an issue. Writing at audio/video rates can be a problem, when the FAT starts getting full, or the disk badly fragmented, and there are long searches needed to find free allocation blocks.

I have been concerned with the pipe organ record on the faster stm32 and the slower SD cards. Being able to use a second processor to handle the dynamic FAT allocation and directory updates asynchronously, may be the answer.

Roger: if you have not done so, look at how elm chan (who is really the cat) did the 8 pin wave player with the AVRTiny85. The bottleneck procs are in AVR asm, but it does show how to set up the buffers for direct playback. Sort of a psudo DMA.

Pico

I came to the same conclusion.

If you set pinMode after Begin its ok. I.e SPI doesn’t seem to clash with using the pin as GPIO.

However begin() is also called in setDivider() and setBitOrder as all thse functions basically have to configure the SPI control reg.

So the quick and dirty fix is to set PA4 to OUTPUT at the end of the begin() function.

we need to handle SPI2 and on some boards also SPI3. But we can put in a switch() to handle this.

But, I’m a bit concerned about the code putting pins into OUTPUT , in case for some bizarre reason, someone had for example decided to use PA4 as an input for flow control, like the Data Req line on the VS1003. As in that case, it would potentially damage some hardware.

So..
I think the best option is to write some code to get the pinMode of the relevant NSS pin before setting the SPI control reg, and then set the pinMode back to the saved state after setting the SPI control reg.

I know this will marginally slow things down, but SPI begin() is not normally called in time critical locations in the code.

@sheepdoll

Thanks for the info on the other File System code.

Using SD is a pain, as it only allows one file handle open at a time
So I can even get a directory list, and then play the files one by one, because the directory list needs a file handle.

I did try writing a work around for the directory list stuff ( as I didnt need recursion into directories, I just stored how many files in the directory, that the MP3 player had played, then started each directory listing from the beginning and skipped over N files to get to the next one to play; but its all a bit hacky) I did consider a linked list for my files list, but malloc is likely to allocate loads of mem for a 8 + 3 file name string, so gave up on that idea.

I think in the longer term we should be able to get the latest version of SdFat working, as it somehow works for Victor.

RogerClark wrote:

Using SD is a pain, as it only allows one file handle open at a time
So I can even get a directory list, and then play the files one by one, because the directory list needs a file handle.

@sheepdoll

I’d tried to use the listfiles demo, and then for each file it iterated, I called my playFile(char *fileName) function

But playFile needs to open the file to plat, and the listfiles loop still has the “dir” file open.

So what seems to happen is it plays the first file, but when playFile function returned, the dir file handle seemed to have been corrupted because playfile has open a file to play

I thought that there was something in the SD lib that uses a global for the file it has open.

But perhaps what was really going on was that the SD read code was getting knackered because of the issues with Chip Select on PA4 not really working.

I’ll need to have another go at using the code from the listfiles example

I could just allocate a big array for the filenames, but it seemed like a hacky way to do it.

RogerClark wrote:I could just allocate a big array for the filenames, but it seemed like a hacky way to do it.

I was only planning to play all the files in a single director and not worry about descending into sub dirs, so I I did was have a number which was effectively indexing N files into the directory

Initiall N = 0

so it opens the dir, skips N files and then reads the file name, stores it, closes the dir file handle, increments N and calls playFile
Loop back around unless N > files in the current folder

ie I only need to store an int for N and also the folder path

I agree to write a general purpose play all files in all folders is far more complex. I was just relying on the high level functions in the SD lib, and only going to play files in the selected folder

RogerClark wrote:I was just relying on the high level functions in the SD lib, and only going to play files in the selected folder

@sheepdoll

I’d not really considered playlists, but I know what you mean

My primary focus was initially just getting the SD and VS1003 stuff working, and I was interested to see if I could DMA to the VS1003 (though I’m having problems with that at the moment), and start the DMA transfers (of the 32 byte blocks), from an interrupt generated by the VS1003 with its Data Req line

So that the system becomes entirely interrupt driven for both the SD and the VS1003, leaving the main loop to handle UI

But thats a long way down the track

Since I’ve been unblocked by this NSS issue, I’ve done some more tests…
There is a new issue I’m facing with SD lib :
I’m mounting the SD.begin(), I’m doing a list printDirectory() provided in example, it work’s fine ! I’m doing it again, it works fine !
I’m doing fileRead(), the fileRead() work fine by itself, but doing printDirectory() give me only few files from the real list …
(I pay attention to what Roger said, I’m closing the handle in printDirectory(), but still there is a new bug …)

Martin

I suspect these are bugs in SD lib and perhaps would be present on AVR (as we’re using the same code)

From what I understand SD has been superseded by SdFat, but the problem with this appears to be Victor sent a pull request to the SdFat repo which was accepted but SdFat no doesnt compile on STM32

Victor_pv has an updated SdFat on his github account, but it didnt work for me (regardless of which CS pin I used), and I suspect it may not compile for F4 because of the F1 DMA stuff thats in that version ;-(

So were does this leave us…

Perhaps going back to the version of SD Fat prior to Victors pull request acceptance may work..

I was thinking we should probably create a separate thread for SPI lib issues, since that’s more general than the SD stuff, and may need a bit of thought and discussion as how best to proceed.

As for SdFatLib, I have some experience in porting that to the mighty-1284p project, so I know my way around reasonably well, and could have a look at porting for the simple non-dma SPI case, since we have a workaround for that now.

BTW, the CSN bug for F103 also affect F2 and F4 devices, but supposedly doesn’t affect F0 and F3 devices (from reading on the my.ST.com forums.)

@pico

Thanks for the heads up about F0 and F3

I’m actually looking at a fix for it this evening (now)

I’m writing a new low level function

gpio_pin_mode gpio_get_mode(gpio_dev *dev, uint8 pin);

I’m unclear what you are actually fixing with this. Can you explain your reasoning?

In any case, start a new thread for SPI lib issue?

I’ll start a new thread

Thread continued here

http://www.stm32duino.com/viewtopic.php?f=14&t=300

Hello,

I’m working with and SD for read/write on a maple mini clone and using standard Arduino SD class.

I’ve found that using this library with an ancient 32Mb (yes, Mb, not Gb) I have to add any debug (Serial.println) or delay(1) between each File.read() because if I don’t do so read fails.

What’s recommended library for this board? Reading the thread I assume Maple Mini is supported by new library, isn’t it?

Naguissa

I’ve also noticed that I needed to add delays. This may be an issue with the speed of your SD card, but I think the old SD library has some “issues”
BTW. Have you tried the latest version of the repo with the change to spi_f1.c, as part of my problem (requiring the delays) seemed to be the issue with using PA4 as the SS pin.
But if you are using another pin, its definitely the SD lib or your card that’s the problem.

I know Victor_pv was working with the author of

https://github.com/greiman/SdFat

Which is the replacement for SD on all Arduino’s

However at the moment it doesn’t seem to work. In fact that repo doesnt compile at all.

Victor_pv has an update SDFat on his github account, but it didnt work for me, so I’m back on the old SD lib which works 95% of the time

RogerClark wrote:Naguissa

I’ve also noticed that I needed to add delays. This may be an issue with the speed of your SD card, but I think the old SD library has some “issues”
BTW. Have you tried the latest version of the repo with the change to spi_f1.c, as part of my problem (requiring the delays) seemed to be the issue with using PA4 as the SS pin.
But if you are using another pin, its definitely the SD lib or your card that’s the problem.

I know Victor_pv was working with the author of

https://github.com/greiman/SdFat

Which is the replacement for SD on all Arduino’s

However at the moment it doesn’t seem to work. In fact that repo doesnt compile at all.

Victor_pv has an update SDFat on his github account, but it didnt work for me, so I’m back on the old SD lib which works 95% of the time

I think that SDFat is the replacement for SD on all Arduinos, but that the Arduino team is slow to roll out this sort of change
I’ve noticed that the IDE Team don’t update the libs very often, and the website doesnt get updated that frequently either, so some stuff on the website is not correct either.

Just a short info:
SDfat lib is currently working, see
http://www.stm32duino.com/viewtopic.php?f=13&t=20