Hi I am using shared SPI Lines between External Flash and SD Card. For SD Card i use MSP430's SPI Engine, however for External Flash I am using same SPI Lines but as GPIO BitBanging.
The SD Card is a very rarely used and hence even the init functions are not called.
The issue:
I observed that if SD Card is inserted but never used, and External Flash is accessed, there is a sudden current increase (13mA) and does not reduce until SD card is removed. If SD card is not inserted there is no such issue.
The CHIP SELECT of the SD card is never touched and is always HIGH, yet the communication over FLASH is effecting the SD Card's sleep modes. According to Sandisk's datasheet the SD automatilly enters sleep mode.
Observations:
Ø Both SD and flash use common SPI lines, all 4 lines state is observed in both HIGH and LOW current states and observed no difference
**LINE HIGH Current Low Current**
Clock H H
D_Out H H
D_In H H
SD_CS H H
Ø **SD Card Removed**
Clock H H
D_Out H H
D_In H H
SD_CS H H
> Observed that changing the BitBanging to SPI ENGINE for both FLASH and SD card has no such current issues.
Checked the Line states if used in SPI Engine but found all signals as same.
Tried making all signals LOW when not in use but no difference.
Queries?
1. IF SD Card's Chip SELECT is HIGH (CS is active LOW) why is SD card not maintaining its SLEEP mode ?
Why both BitBanging and SPI Engine communications work without issue but effect current consumption in SD card though SD card is not communicated with ?
Limitations
I cannot use FLASH in SPI ENGINE mode and it is important for me to use only BitBanging.
The device is required to consume least power at all times and should work for 1 year on battery.
First, you need to mention the SD card,SPI FLASH and MSP part numbers (a pdf link is preferable) as the answer may lay in the documentation. Have you studied all the conditions that can take the SD card in and out of SLEEP?
There might be some register initialization required for the card to persist in sleep mode when there is activity on the SCLK line.
Second, find out the exact moment (instruction) on which the current spikes. Is it when SCLK goes high for the first time, or maybe when MOSI goes high?
Third, if possible, measure the current consumption of all 3 involed chips separatedly (MSP, SD, FLASH) to pinpoint who is generating this extra consumption.
Is the SD card powered while not in use? If it isn't, then it can feed through the I/O lines when they are high.
Mind sharing the reason for not using the SPI engine to communicate with the FLASH chip? And why share the pins? If you want the lowerest power consumption, bitbanging is NOT the way to go.
Related
I want to read and transfer more than 32 bits over SPI using teensy 4.1 on Arduino IDE.
Hi! I want to read binary data comprising of 100 bits. The data is synced at 1.8Mhz clock and I am able to sync Teensy 4.1 with it. What I want to do is, I want to read that data through SPI with no CS pin by making the SPI clock 1.8Mhz. I achieved this but the microcontroller SPI is running in non-continuous mode i.e., by observing the signals on Oscilloscope,
> CS goes LOW
> 32 Clock pulses
> CS Goes High
> CS Goes low
> again 32 clock pulses.
> CS goes low
again, I am reading data over SPI just using the MOSI and MISO pins. Clock and CS pins are for observation only.
Recently, I bought a Nucleo-144 development board for the STM32F746. For the project I'm working on, I need to get consistent >3 MB/s write speeds to the SD card. Using STM32CubeIDE, I've been able to get SD 1-bit mode working with FatFS in both polling and DMA modes at full speed. However, switching to SD 4-bit mode, I start getting lots of IO errors relating to bad data CRCs while reading.
Details
In SD 4-bit polling mode, I can't even get a single block read to process correctly. Calling f_mount returns an IO error, and debugging it further reveals that the first call to HAL_SD_ReadBlocks, reading sector 0, fails with the error code SDMMC_ERROR_DATA_CRC_FAIL:
Inspecting the 512 byte data buffer it's read to from the card reveals that data is at least partially intact containing some strings you'd expect to see in the first sector:
Importantly, this buffer is corrupted in the exact same manner between each run of the software. If it was some kind of electrical interference problem, I'd expect to see different bytes being corrupted, but I don't. The buffer is identical between runs. Switching back to 1-bit mode and inspecting the data buffer, it's clearly in a lot better shape. The 4-bit buffer clearly has a lot of corrupted bits and bits that are missing entirely, offsetting everything. 4-bit mode is reading mostly junk, but consistently the same junk.
What I've Tried
Polling and DMA mode.
Both fail in a similar manner, although it's harder to debug DMA.
Decreasing the SDMMCCLK clock divider all the way down to 255, the highest divider (and lowest clock speed) it'll go.
On my older, cheaper, Lexar SD card read/writes in this mode work flawlessly (albeit very slowly).
On my newer, more expensive, Samsung SD card read/writes still fail with a SDMMC_ERROR_DATA_CRC_FAIL error. The data buffer appears much more intact, but it's clearly still garbage data.
Transfers with GPIO pull-ups applied to all SD pins (except clock) as well as without pull-ups.
No change, at least as far as I could tell.
Using multiple different SD cards.
Specifically, a Lexar "300x" 32 GB card and a Samsung "EVO Plus" 128 GB card.
As mentioned previously, decreasing the clock speed allowed one of my two cards to work.
However, my higher quality card still fails on the first read even at the minimum speed.
Wiring
Not sure how relevant this is, but figured I'd include it for sake of completion. This is how I have my SD card connected while prototyping. All of the cables are the same length, but perhaps they're interfering with each other even over such a short distance? I'm also using an Adafruit SD card breakout adapter for testing.
SD Card
GPIO Pin
CLK
PC12
D0
PC8
CMD
PD2
D3
PC11
D1
PC9
D2
PC10
Summary
It appears that with some cards, even at lower clock speeds, IO errors are incredibly common in SD 4-bit mode only. At higher clock speeds, all cards I'm able to test with start having IO errors in 4-bit mode. In SD 1-bit mode, however, even at the maximum clock speed I'm able to read and write fine.
I'd like to take advantage of the 4-bit mode for faster speeds. What am I doing wrong? Is it something electrical, like for example needing stronger pull-up resistors or shorter wires? Thanks, I really appreciate it!
I had similar issues on a H743ZI Nucleo. My code worked fine on two other H743 boards with onboard sdcard readers, but failed on the Nucleo with Adafruit breakout. I believe it was just due to signal integrity..
I see you tried dropping the clock divider down, but have you tried a slower SDMMC clock? This was what made the difference for me. Was failing at 48MHz, but fine at 24MHz and lower with 0 divider.
I am interfacing SD cards (1/2GB SD cards and 4GB SDHC cards from different manufactures) to a custom board in SPI mode and I am using a FATfs file system from elm-chan.
I am able to write files and read files on the SD card. However I would like to know where can I get the information on the maximum clock frequency (I can drive my SPI bus) for the given SD card.
I have seen that for some SD cards maximum speed was about 1.33MHz and for some 20MHz.
I assumed this speed was in the CSD register (TAAC value, as the TRAN_SPEED was the same on all the cards set at 25Mhz). However I realized its not true. I would really appreciate if someone can share their knowledge on this. Thanks!
Without a clear part number of the SD card, it is not feasible to find it. The probability of getting a correct answer is high only if you can share the exact details. I suggest you to check the specification thoroughly of the respective SD card for a quick answer. Can you confirm whether the observation done by you is different from the information provided in the specification ?
I have a microprocessor with the card's chip select (CS) line tied to a 'frame' signal automatically driven by the SPI (SSP) circuit. This causes CS to go high between each byte.
The MMC/SD specs require that CS be held low in order to enter SPI mode. Does it need to be held low the entire time, or only when transmitting each byte of CMD0?
At the sdcard.org site, I found various PDF specifications for SDIO. None of these seem to have an explicit timing statement which clarifies this. However, this statement does occur:
(1) SD Bus mode is selected by CMD0 (Keep Pin 1 to high during CMD0 execution).
from page 88 of SD Host Controller Simplified Specification Version 2.00. ("Pin 1" is Chip Select (CS))
Given that sentence, an SD card manufacturer would be justified in requiring that you assert CS through the entire D0..D15 bits being sent. In other words, I think you cannot use the SPI frame signal and will need a GPIO pin or similar.
I saw a lot of information about MMC/SD cards and I tried to make a library to read this (modifying the Procyon AVRlib).
But I have some problems here. I don't change the original code and tried here. My problem is about the initialization of an SD card. I have two here, a 256 MB and another 1 GB.
I send the init commands in this order: CMD0, CMD55, ACMD41, and CMD1.
But the 256 MB SD card only returns a 0x01 response for each command. I send the CMD1 a lot of times and the 256 MB SD card always returns only 0x01, never 0x00.
The 1 GB SD is more crazy... CMD0 returns with 0x01. Nice, but the CMD55 command responds with 0x05. At other times it responds with 0xC1 and also sometimes responds with 0xF0 with a 0x5F in the next interation...
Around the Internet there is information and examples, but it is a bit confused. Here in my project, I must use a 1 GB card and I'm trying with a microSD card with an SD adapter (I think that this is not the problem).
How do I fix this problem?
PS: My problem is like the problem in Stack Overflow question Initializing SD card in SPI issues, but the solution didn't solve my problem. The 1 GB SD card only returns 0x01 ever... :cry:
Why do you need CMD1? And did you read the note below it, that says "CMD1 is a valid command for the thin (1.4 mm) standard size SD memory card only if used after re-initializing a card (not after power on reset)."?
About the 1 GB card, ideas that come to mind:
After every command (send command, get reply), do you send 8 dummy bytes before making CS high?
The values returned seem weird (0x05 doesn't have busy bit set, so WTF?), maybe there's a hardware issue?
Does the card work otherwise?
Maybe this helps a bit:
SD Specifications Part 1 Physical LayerSimplified Specification
A simple explanation of MMC/SD usage over SPI is provided here. I have used the associated FAT file-system library too and it works well.
However, the solution may not work for some makes of cards. For such cards, you may have to edit the procedure/library. That may be why your 1 GB card acts differently -- it may be a different make of card. The SPI mode of certain cards may not be that popular for commercial equipment, and thus may be more deviated in specification by some card manufacturers.
If you bit bang the commands and clocks, you may have more control and confidence that those procedures are correct. That is useful because you need some solid ground to build on to progress bit by bit. I found that the <400 kHz 80 clocks was critical on one card, but could run at more than 2 MHz on another.
Try to progress one command at a time that is reliable for both cards.