RAK4631 + 15002
I’ve been fighting with the SD card initialisation for a few days.
Are there any known issues with SPI under RUI3?
No known problems. I am using the SD card module in the RAK10706 Signal Meter without problems. Source code ==> RAK10706-Signal-Meter
What other modules are you using on the Base Board?
GPS and EEPROM, both inactive at the moment.
It looks like the CS and SCK, MOSI and MISO are all doing the right
thing, but I can’t get two probes onto the thing at the same time as
drive the scope so I can’t be certain of the timing. (Using standard
MSB and SPI_MODE_0)
I get different R1 response if I assert SPI_CS before or after
Serial.beginTransmission. In both cases Serial.transfer is later.
Even if inactive, remove both and try again.
SPI CS has to be handled manually, in my example code it is done in the library I use for the SD card.
Yeah. I’ve been through the SD library code base carefully and AFAIK I’m doing exactly the same stuff. There are things that the library does like asserting CS twice without the deassert in between. But that’s the sort of reason I don’t want to use it. That and I don’t want the FAT layer anyway.
It’s especially annoying because I have written SD card access code before (in MSP430 assember) and had no problems.
The only connections on the RAK15002 (SDcard) are the four SPI dedicated lines and the card detect which is IO6. The card detect function DOES work.
The SPI chip select is however it is internally mapped with:
digitalWrite(SPI_CSN_PIN, false);
and this is driving the SDcard holder pin.
The EEPROM only has I2C. The 12500 GPS does have something labeled IO6 but in slotA that’s mapped the IO2. Neither of these can interfere with the SPI lines.
Anyway, getting code to load again at all is the first priority.
For what it’s worth, I removed the GNSS from slotA and the EEPROM from slot C and tried again.
It made no difference.
We can close this out. The short version is that in SDcard comms via SPI:
Chip Select (CS) assertion and de-assertion needs to wrap the each command and its paired response. You can’t string a bunch of commands together under one CS cycle and you can’t seperate the command and response into their own CS cycles.
Any finally, sometimes (??) you need to wrap some spare 0xff transfers on each side of the CS events. I haven’t completely groked the rules on that and it does no great harm to leave the padding in there.