Works for 3.3V eMMC in 4 line mode.
Not implemented:
- DDR mode for SD cards (UHS-I) also need voltage to be switched to 1.8V.
- 8-line DDR mode for eMMC to be implemented later.
Perviously host send_auto_stop flag would be set for every data
transfer over 1 block long. This caused stop commands to be sent
after CMD53, which shouldn't be done. Fix by adding an explicit list
of commands for which send_auto_stop should be set.
This fixes errors logged on the console: sdmmc_req:
handle_idle_state_events unhandled: 00000004 00000000
The issue happens if "data done" event occurs before "command done".
State machine code did not check *which* event occurred in
SENDING_CMD state, and went to IDLE or SENDING_DATA state on any
non-error event. In this case, we can't process "data done" event
until command has completed. This change introduces "unhandled event"
mask, which is carried over from one run of process_events to the
other. This allows waiting for the "command done" event to complete,
and then process "data done" event.
Ref TW17126.
CMD53 in byte mode supports transfers of any number of bytes between 1
and 512. This change removes limitation that the number of bytes must
be divisible by 4. Host quirk, that such transfers must be split into
two commands (one for the aligned part and the other one for
unaligned) is taken into account.
Existing code assumed that response timeout is not followed by CMD_DONE,
which was not true, in fact. Host datasheet states that CMD_DONE is sent
after an RTO.
All the commands which do not have a response must have their flags set
accordingly. Therefore the host will not send RTO interrupt if response
is not expected. It is a bug in the code logic if it happens otherwise.
SET_BUS_WIDTH is not a data transfer command. Extensive search in the
host datasheet and SD card spec did not reveal the origin of this hack
or 'feature'. Further testing showed that removing this does not lead to
regressions.
Previously the timeout was set to the same value (1000ms) for all kinds
of commands. In some cases, such as with slow cards, write commands
failed to complete in time.
This change makes command timeouts configurable via sdmmc_host_t
structure, and also makes default timeouts different for ordinary
commands and write commands.
Closes https://github.com/espressif/esp-idf/issues/1093
Ref TW15774.
‘make_hw_cmd’ function checks opcodes in a few cases. Comparing opcode
does not tell the whole story, because for some SD commands there is are
APP commands with the same opcodes. This change introduces a flag which
indicates whether the next command is going to be an APP command.
The check for APP_SET_BUS_WIDTH command is updated to use this flag.
This fixes a bug with an unexpected STOP_TRANSMISSION command sent after
SWITCH_FUNC command, which has opcode 6, same as APP_SET_BUS_WIDTH.
MMC_RSP_BITS helper function had a hack that it flipped word order in
the response, assuming that response size is 4 words. This hack does not
work for responses which are not 4 words long (such as the SWITCH_FUNC
response, which is 64 words long).
This change removes the hack and the matching word order reversal code
in sdmmc driver.
SDMMC hardware treats all buffers as aligned, and ignores 2 LSBs of
addresses written into DMA descriptors. Previously SDMMC host driver
assumed that data buffers passed from SDDMC command layer would be
aligned. However alignment checks were never implemented in the command
layer, as were the checks that the buffer coming from the application
would be in DMA capable memory. Most of the time this was indeed true.
However in some cases FATFS library can pass buffers offset by 2 bytes
from word boundary. “DMA capable” restriction may be broken if pSRAM
support is used.
This change adds buffer checks to the SDMMC host driver (alignment and
DMA capability), so that the host layer will error out for incompatible
buffers. In SDMMC command layer, a check is added to read and write
functions. If an incompatible buffer is passed from the application, new
buffer (512 bytes size) is allocated, and the transfer is performed
using {READ,WRITE}_SINGLE_BLOCK commands.
When SD card is removed during transaction, SDMMC peripheral can report
a range of errors, such as timeouts, CRC errors, start/end bit errors.
Under normal conditions (card is inserted), SDMMC peripheral also generates
command done or data done interrupts. When the card is removed, such
interrupts may not be always generated.
This change fixes handling of timeout interrupts and SBE interrupts.
It also adds a one second timeout into the event processing loop. This
timeout allows applications to recover in cases when the SDMMC peripheral
doesn’t generate command/data done event on card removal.
