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.
Related
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 using a STM32F031K6, clocked at 40MHz, and I want to design a program which acts as a looping shift register - an external trigger is used to clock it, the values in the shift register left shift every time a rising/falling edge is received. the output is one pin either high or low.
I need to make the time between the clocking edge and the output less than 0.5uS, or failing that as quick as possible. The values of the shift register can be changed and the length can also be changed, but for now I'm just starting with a byte like 11000010 .
I initially thought to implement this with an external interrupt but it was suggested there may be a better way to implement it
any help much appreciated
You might use the SPI peripheral of the STM32F0 for your task. When configured in slave mode, each time an external clock edge is detected on the SCK signal, the MISO will be set to the next bit of a value loaded into an internal shift register via the SPI data register.
Check out the chapter on the Serial peripheral interface (SPI) in STM32F0 reference manual.
Especially have a look at the sections addressing the following keywords:
General description: SPI block diagram
Slave Mode (Master selection: Slave configuration)
Simplex communication: Transmit-only mode (RXONLY=0)
Slave select (NSS) pin management: Software NSS management (SSM = 1)
Data frame format (data size can be set from 4-bit up to 16-bit length)
Configuration of SPI
The SPI unit is highly configurable, e.g. regarding the polarity of clock signal. Since it is an independent hardware unit, it should be able to handle your 0.5us reaction time requirement. The MCU firmware needs to set up the SPI unit and then provide new data to the SPI unit, each time the Tx buffer empty flag (TXE) is set. This can also be done by interrupt (TXEIE) or even using a DMA channel (TXDMAEN) with a circular buffer. In the latter case the "shift register functionality" runs completely independent of the MCU core (after setup).
I'm a beginner in the embedded system development world.
I would like some clarifications on the following questions.
Is every pin of a microcontroller (from here after referred to as mc) associated with a register?
Is it an one to one relationship?
How are ports (or groups of pins) assigned inside the mc?
Is it only possible to set a single pin low or high only?
No. Some pins are not associated with a register at all, e.g. Vcc and GND and if they do not have a dual use as a GPIO it also applies to clock/oscillator and reset pins.
If a pin is associated with registers, it is usually associated with several ones: one for determing the IO direction, one for reading the input, one or more for setting the output. For I2C, SPI, UART pins, the associated is indirect, i.e. the register mainly control the I2C/SPI/UART controller, which in turn is associated with the pin.
I don't understand the question
A GPIO pin can be set as input, as output in high state (delivering current or with a weak pull-up), as output in low state (sourcing current or with a weak pull-down) or in open-drain state (often similar to input mode). A pin can also be configured to be used by one fo the I2C/SPI/UART controllers or as DAC (outputting a variable voltage between GND and Vcc).
In addition to fundamental stuff like supply and clock pins, a MCU got numerous hardware peripherals internally. A hardware peripheral being something like a piece of GPIO (general-purpose input/output), ADC, UART, SPI etc. Each such hardware peripheral has a number of possible pins to which its functions can be routed.
Traditionally, these were pretty much fixed - if you wanted UART Tx then you would always get it on some fixed pin number, take it or leave it. Nowadays, most MCUs are quite flexible internally, allowing you to re-route hardware peripheral functionality to almost any pin you like, variably.
In either case, several hardware peripherals could share the same pin, and then it is MCU specific which one that takes precedence. For example GPIO could be present on the pin by default, but if you enable UART then maybe the MCU states that you get UART Tx on that pin instead.
As for the hardware peripheral called GPIO, they are almost always grouped in ports, where each port consists of a number of pins. Most often, port registers are either 8 bits or the size of the CPU's word length. Each bit in the various port registers corresponds to a pin.
You'll have a port data register, which is the actual read/write to the pin, a data direction register stating input or output, and then various other registers for interrupts, pull resistor enable etc etc.
Not all pins but all IOs (Input/Output) have a specific register.
Each IO has a specific group of registers. Bu also some registers may include specific bits which effects an IO or all IOs.
It depends of design of micro controller.
Yes it is.
I strongly recommend you to read some embedded hardware/software books(for example Newness Know It All books for embedded systems) and datasheets.
Consider you have an SPI bus with only a single chip select.
Is there a chip such that I can connect 8 or more devices to that SPI bus?
To simplify things, you may assume that all devices agree on the SPI mode (data needs to be valid on a rising edge). Also, all devices are of the time, where chip selects stays low for the whole transfer, and is not toggled after each word.
The SPI multiplexer could have 4 inputs:
MISO, MOSI, input clock, master chip select
and 9 outputs:
output clock, 8 slave chip selects
MISO and MOSI are connected directly to the slaves. The slaves have their SPI clock connected to the output clock and their chips selects are connected to one of the 8 slave chip selects.
The SPI multiplexer would take the two bytes of each SPI transfer as its own input. The first byte could indicate which slave is to be selected. For configuration of the multiplexer, a ninth address could be allowed.
If one of the 8 slaves is selected, the multiplexer would then activate the slave's chip select after the first byte (or even after the first few bits of the first byte). The output clock would activate with the start of the second byte and it would be synchronous to the input clock. Leaving the clock inactive during the first byte makes sure that the slaves never take notice of the first byte.
Such a chip does not seem to exist. I found solutions with two chip selects, but that's not an option to upgrade old hardware designs with just a single chip select.
Does such a thing exist?
It does not exist because there is no need for it. Often CS is only controlled from software as a regular gpio before initiating an SPI transfer, then you could just wire the different slaves to different GPIO and use them as CS. If the CS is generated and needed by the hardware block you gate this signal with the external chip select to choose the wanted slave.
Your proposed one byte to select bus would also break all software which relay on writing from and reading to the same buffer, and it would be decrease the available bandwidth with control signals.
As a side note with recent development with secure enclaves and Trustzone the trend is not to share spi buses but rather hard wire them so only code running in the trusted part of the SoC will be able to access the connected slave.
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.