issue with sd card

hello

i have this SD module, sdfat version 1.0.3, external ttl-serial, low (4mhz) speed, stm32duino core last update (20 of this month)
if i use it on maple mini (from baite) it works ok
same code on the bluepill gives me initialization error

I am using this
#include <SPI.h>
#include "SdFat.h"
SdFat sd;
File file;
char fileName[] = "log_1.csv";
byte fileNumber = 1;

#define SD_CHIP_SELECT PA4 //53 mega, 10 uno, 7 (PA4) STM
#define SPI_SPEED SD_SCK_MHZ(4)
#define baudrate 115200
#define Serial Serial1

void setup() {

Serial.begin(baudrate);

Serial.println("type to start");

while (!Serial.available()) {
SysCall::yield();//avoid error on other boards?
}

Serial.println("Starting...");

if (!sd.begin(SD_CHIP_SELECT, SPI_SPEED)) {
Serial.println("initialize error");
}

Serial.print("file Name: ");
Serial.println(fileName);

while (sd.exists(fileName)) {
newfile();
Serial.print("file name: ");
Serial.println(fileName);
}

file = sd.open(fileName, FILE_WRITE); //create file

if (file) { //check if file is opened correctly

file.println("test 1");

for (int i = 0; i < 20; i++) {
file.print("data"); file.print(i); file.print(",");
}
file.println("");

file.println("test 2");
char randomData[100];
byte value1 = random(0, 254);
int value2 = random(254, 65536);
char value3 = 'p';
float value4 = random(1, 500) / 100.0;
sprintf(randomData, "value:%d,%d,%c,%f", value1, value2, value3, value4);
file.print(randomData);
file.println("");

file.println("test 3");
unsigned int start = micros();
file.print("writing speed: ");
unsigned int speedtest = micros() - start;
file.print(speedtest);

file.close();

delay(10);
Serial.println("wrote!");
Serial.println();

delay(1000);
Serial.println("stress test...");
delay(10);

for (byte a = 10; a >= 1; a--) {
char fileName[12];
sprintf(fileName, "file%d.csv", a);
file = sd.open(fileName, FILE_WRITE); //create file
delay(100);
if (file) {
file.println("stress test");
} else {
delay(100);
Serial.print("stress test failed n#"); Serial.println(a);
}
delay(100);
file.close();
delay(20 * a);
}

Serial.println("completed!");

} else {
Serial.println("error opening file");
}
}

void newfile() {

fileNumber++;
sprintf(fileName, "log_%d.csv", fileNumber);

}

void loop() {}

Which core exactly?
stm32duino = https://github.com/stm32duino/Arduino_Core_STM32F1 ?
or
Arduino_STM32 = https://github.com/rogerclarkmelbourne/Arduino_STM32 ?

Roger’s one
The only things that i changed between the two boards is the upload method, bootloader with the mm and stlink with the bluepill

are you using greiman’s sdfat?
https://github.com/greiman/SdFat
https://github.com/greiman/SdFat-beta/t … /SdFat/src
and pulled in the correct SPI.h and SPI.cpp into your build path?
https://github.com/rogerclarkmelbourne/ … raries/SPI

and u’ve got the pins correct?
these are for SPI1
PA4 – SS1 – you could use this as your chip select
PA5 – SCK1
PA6 – MISO
PA7 – MOSI
they need to goto the correct pins on sd card
http://www.interfacebus.com/Secure_Digi … inout.html

my own codes looked something like this
#include "SPI.h"
#include "SdFat.h"

const uint8_t chipSelect = PA4
SdFat sd(1);

void setup() {
if (!sd.begin(chipSelect, SD_SCK_MHZ(50))) {
sd.initErrorHalt();
}
...
}


@aster,
please extend the part of your code when checking for sd.begin with
if (!sd.begin(SD_CHIP_SELECT, SPI_SPEED)) {
sd.initErrorHalt(); ////////////////////////////////////////// insert this to see error code
}

yes, i use greyman sdfat “normal” library: https://github.com/greiman/SdFat
yes, the ide is using the correct SPI lib
pins are correct, i usually use this https://developer.mbed.org/media/upload … nout01.png or this http://wiki.stm32duino.com/images/a/ae/ … pinout.gif

output of sd.initErrorHalt();
Can’t access SD card. Do not reformat.
No card, wrong chip select pin, or SPI problem?
SD errorCode: 0X20,0XFF

from SdInfo.h 0x20 seems to be a general error
// Basic commands and switch command.
SD_CARD_ERROR_CMD0 = 0X20,
i didn’t find 0xff, but it seems to be something generic too

Test code:

#define Serial Serial1

#include "SPI.h"
#include "SdFat.h"
const uint8_t chipSelect = PA4;
SdFat sd(1);

void setup() {
Serial.begin(115200);
while (!Serial.available()){
Serial.println("wainting");
}

delay(100);

if (!sd.begin(chipSelect, SD_SCK_MHZ(4))) {
sd.initErrorHalt(); // sd.initErrorPrint();
}
}

void loop() {}

Error code 0x20 means that the very first command sent to SD fails (no valid answer within a preset time).
Can you check the SPI clock and chip select lines with a scope?

EDIT
Also check the 3.3 V on the card module.
It is well known that the 3.3 V regulator on the blue pill is not very strong, in which case I recommend to use a separate 3.3V supply (eventually from the MM) for the SD card module alone.

i don’t have a real scope… only “this”: https://www.hackster.io/vincenzo-g/diy- … zer-f61ee5
i could try with it using SD_SCK_MHZ(1), maybe it will work

I already use the 3.3V from a stand alone supply

Hm, everything looks fine…
Maybe a missing common GND line between SD module, BP and the external power supply?
Do you have a picture of your setup with BP (not with MM) ?

[aster – Wed Jul 26, 2017 12:26 pm] –
i don’t have a real scope… only “this”: https://www.hackster.io/vincenzo-g/diy- … zer-f61ee5
i could try with it using SD_SCK_MHZ(1), maybe it will work

I already use the 3.3V from a stand alone supply

now your logic analyzer is *really* useful, but my guess is like steve suggested check the other basic things 1st, power rails etc which basically need a voltmeter, it would seem rather unlikely that it works on MM but break on BP, unless perhaps some broken/cold solder joints etc perhaps, oh & i get 0x20 if i forget to plug in the card or the card is loose
i think steve may be right about the LDO though, some SD cards may draw quite a bit of current/power and may not work properly if the LDO can’t supply that much, some LDO supply a measly 100ma, but i think the AMS1117 on baite mini can supply up to 1A, that’s pretty beefy
http://www.advanced-monolithic.com/pdf/ds1117.pdf

setup:
powered from the ldo of the baite mini

“logic analyzer” capture:
12 is clk
13 – mosi
14 – miso
15 – ss

It looks like you have a short between PB12 and 15.
PB13 seems like a good SS candidate.

Why do you connect MM and BP in parallel? This way the pins can conflict with each other.

[stevestrong – Fri Jul 28, 2017 11:23 am] –
It looks like you have a short between PB12 and 15.
PB13 seems like a good SS candidate.

yep, you are right… weird and more weird
i am quite sure the problem is with the BP i will just buy a few new boards and check what it is happening

[stevestrong – Fri Jul 28, 2017 11:23 am] –
Why do you connect MM and BP in parallel? This way the pins can conflict with each other.

it is my “logic analyzer”

https://www.aliexpress.com/item/10pcs-l … a436d2542d

even though i’ve got a few BP with still unsoldered headers, i’m <no longer> tempted too late succumbed
stephen

I would first write a simple test program to toggle each pin in part, and monitor the output.
I used to write a counter which outputs the result on the respective pins to be tested, so that you can differentiate the pins by the toggle frequency.
This test would for sure detect any short on pins.

it is my “logic analyzer”
wow, this time u’ve got a *real* logic analyzer