[Ovmsdev] OVMS v3 getting started

[Mark Webb-Johnson]

We’re using the circuit design from Espressif.

https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card <https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card>

ESP32 pin	SD card pin	SPI pin	Notes
GPIO14 (MTMS)	CLK	SCK	10k pullup in SD mode
GPIO15 (MTDO)	CMD	MOSI	10k pullup, both in SD and SPI modes
GPIO2	D0	MISO	10k pullup in SD mode, pull low to go into download mode (see note below!)
GPIO4	D1	N/C	not used in 1-line SD mode; 10k pullup in 4-line SD mode
GPIO12 (MTDI)	D2	N/C	not used in 1-line SD mode; 10k pullup in 4-line SD mode (see note below!)
GPIO13 (MTCK)	D3	CS	not used in 1-line SD mode, but card's D3 pin must have a 10k pullup
N/C	CD		optional, not used in the example
N/C	WP		optional, not used in the example
This example doesn't utilize card detect (CD) and write protect (WP) signals from SD card slot.

With the given pinout for SPI mode, same connections between the SD card and ESP32 can be used to test both SD and SPI modes, provided that the appropriate pullups are in place. In SPI mode, pins can be customized. See the initialization of sdspi_slot_config_t structure in the example code.

 <https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card#note-about-gpio2>Note about GPIO2

GPIO2 pin is used as a bootstrapping pin, and should be low to enter UART download mode. One way to do this is to connect GPIO0 and GPIO2 using a jumper, and then the auto-reset circuit on most development boards will pull GPIO2 low along with GPIO0, when entering download mode.

 <https://github.com/espressif/esp-idf/tree/master/examples/storage/sd_card#note-about-gpio12>Note about GPIO12

GPIO12 is used as a bootstrapping pin to select output voltage of an internal regulator which powers the flash chip (VDD_SDIO). This pin has an internal pulldown so if left unconnected it will read low at reset (selecting default 3.3V operation). When adding a pullup to this pin for SD card operation, consider the following:

For boards which don't use the internal regulator (VDD_SDIO) to power the flash, GPIO12 can be pulled high.
For boards which use 1.8V flash chip, GPIO12 needs to be pulled high at reset. This is fully compatible with SD card operation.
On boards which use the internal regulator and a 3.3V flash chip, GPIO12 must be low at reset. This is incompatible with SD card operation.
In most cases, external pullup can be omitted and an internal pullup can be enabled using a gpio_pullup_en(GPIO_NUM_12); call. Most SD cards work fine when an internal pullup on GPIO12 line is enabled. Note that if ESP32 experiences a power-on reset while the SD card is sending data, high level on GPIO12 can be latched into the bootstrapping register, and ESP32 will enter a boot loop until external reset with correct GPIO12 level is applied.
Another option is to burn the flash voltage selection efuses. This will permanently select 3.3V output voltage for the internal regulator, and GPIO12 will not be used as a bootstrapping pin. Then it is safe to connect a pullup resistor to GPIO12. This option is suggested for production use.
The following command can be used to program flash voltage selection efuses to 3.3V:

    components/esptool_py/esptool/espefuse.py set_flash_voltage 3.3V
This command will burn the XPD_SDIO_TIEH, XPD_SDIO_FORCE, and XPD_SDIO_REG efuses. With all three burned to value 1, the internal VDD_SDIO flash voltage regulator is permanently enabled at 3.3V. See the technical reference manual for more details.

Only difference is we have a card detect pin wired as well.

No filter and stabilisation caps on the SD CARD side, but we do have on the main power supply.

I have a breadboard version of OVMS v3 (using a standard SD card adaptor) that used to work fine, but is now suffering from the same problem. I just doesn’t seem to work at all since we switched to IDF v2.1 I suspect it is the esp-32 IDF libraries - there has been some recent re-working (in bleeding head) of the SPI libraries, and reports of similar issues. Even if I compile the standard espressif sd card example code, I can’t get it to work now (either on breadboard, or real OVMS v3 hardware).

The strange thing is that the China side are reporting no issues.
'
Regards, Mark.

> On 5 Oct 2017, at 8:00 AM, mr23 at comcast.net wrote:
> 
> I don't have the circuit handy.
> Does the sdcard chip and processor chip have filter caps and stabilization caps (for current draw surge)?
> 
> ------ Original message------
> From: Stephen Casner
> Date: Wed, Oct 4, 2017 6:51 PM
> To: OVMS Developers;
> Cc:
> Subject:Re: [Ovmsdev] OVMS v3 getting started
> 
> On Mon, 25 Sep 2017, Mark Webb-Johnson wrote:
> 
> > I’m having problems getting SD CARDs to work reliably. Some work
> > recognise at all (a timeout error when mounting), and some will
> > recognise but fail under heavy writes to the sd card. Frustrating as
> > hell. I don’t think it is a hardware issue (even the googling that
> > error message points to pull-up resistors as the culprit), but
> > suspect some issue with the ESP IDF 2.1 library we are using. We’re
> > working on this one at the moment. I would appreciate your feedback,
> > when you get the boards, as to whether you get any success with SD
> > CARDs.
> 
> I have a SanDisk Ultra 32GB micro SD card left over from playing with
> a Raspberry Pi.  It is formatted FAT32 with name RECOVERY.  When I
> insert it into the OVMS v3 and try the sd mount command, I get:
> 
> OVMS > sd mount
> Error: SD CARD could not be mounted
> E (75093) sdmmc_cmd: sdmmc_card_init: send_scr returned 0x107
> 
>                                                         -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171005/9caea6e2/attachment.htm>