[Ovmsdev] SD CARD

[HONDA S-2000]

In my experience, it seems that SPI Flash chips from different manufacturers sometimes have slightly different commands. The command sets are largely compatible, but sometimes there will be one or more commands that are not. I mention this because it might be possible to determine why there is a difference between the 4MB and 8MB Flash chips.

Usually, the commands used by a chip at boot time are restricted to those commands that all SPI Flash manufacturers implement, otherwise the chip wouldn’t boot at all. So far, I’ve only seen other commands that vary from the standard. But seeing the variation left me with the impression that SPI Flash communications are not necessarily universal across all makes and models.

This thread seems to have ended, and I’m way behind on email, but maybe the new “SD CARD vs 16MB flash” has resolved the issues.

Brian


On Nov 26, 2017, at 10:01 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> Frustration continues…
> 
> Removing the top metal casing from the WROOM32 module, re-wiring CS line on internal module 4MB flash to a different line, and burning e-fuses: Result is SD CARD works fine. So, issue is not related to the e-fuses or use of flash on non-default CS line.
> 
> Then, I tried an AnologLamb module with 8MB module flash, and a couple of jumper wires to a SD CARD module. Result is that SD CARD doesn’t work. This is a very simple setup - module in a development holder (very neat, highly recommended) and identical firmware flashed to both Espressif WROOM-32 and AnalogLamb compatible version. Plug in the Espressif WROOM-32 module, SD CARD works fine. Plug in AnalogLamb 8MB one, SD CARD doesn’t work. I can’t get it any simpler than that.
> 
> So, either I’m completely missing something important, or the ESP32 SDIO hardware/library isn’t working with anything other than that standard 4MB flash chip. We now don’t think the issue is external/internal flash at all - more the actual flash chip itself.
> 
> The above has been reported to Espressif. They’ve gone silent (ok, it has been the weekend), so hopefully they’ve found the issue and are waiting to be able to give me the good news.
> 
> Regards, Mark
> 
> On 23 Nov 2017, at 1:50 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>> An update on SD card issues.
>> 
>> We’ve (finally) narrowed down the problem. It seems our wiring is fine, pull-ups are fine, and software is as expected. No problem with interference, or power supply.
>> 
>> The issue seems to be a conflict in the ESP IDF (probably bootloader, or ESP hardware) when using our external 16MB flash. Flash memory in the ESP32 is controlled over an SPI bus. We use the same SPI bus pins as the standard on-board flash, but a different CS (Chip Select) line (GPIO22 vs SD3 pin #19 for the standard 4MB flash chip). We burn fuses to tell the ESP32 to use our flash CS line (rather than the built-in one). That’s it. Nothing special, and no pin conflicts. We think some other conflict between the SD CARD and SPI hardware in the ESP-32 chip (perhaps requiring special handling in the bootloader / library code).
>> 
>> Now, when OVMS is using this external flash, and accessing SD CARD, it becomes unreliable. It may seem fine, but read/write a lot and it fails. Replace the WROOM-32 module with one without efuses burnt (using internal 4MB flash), and the SD CARD goes back to working normally.
>> 
>> I’ve finally (god, this has been frustrating) got someone at Espressif to recognise the problem and they are trying to re-create. The solution may be resolvable in bootloader code (best case), or may require a hardware fix. Whichever, we are close.
>> 
>> While researching workarounds, and bearing in mind the latest ESP32 WROVER modules offering external PSRAM (SPI RAM; to expand RAM space in a similar way to external flash expands code space), I found a company called AnalogLamb  These guys make a pin-compatible WROOM32 module including different size FLASH and PSRAM chips. We can get a module with 16MB flash and 4MB PSRAM - giving us the flash space we need, and another 4MB of heap space in RAM. It is not quite a drop-in replacement, as GPIO16+17 are used for the PSRAM (so we would have to move the GPIOs used for our modem), and the PSRAM requires the latest ESP IDF version (which brings other issues with it), but it seems to be a workable solution. I’ve gotten a hold of two sample modules (just arrived today) and will be trying them tonight. I’ll let you know how it works out.
>> 
>> Regards, Mark.
>> 
>> <IMG_5655.jpeg>
>> 
>> On 7 Nov 2017, at 9:11 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>> Edward, Steve: thanks for your feedback.
>>> 
>>> I made some progress. It turns out that the stuck-in-download-mode-after-flashing issue is caused by the SD CARD itself (not GPIO0 as I had thought). If I flash with the SD CARD inserted, I get that issue. If I remove the SD CARD, then reset, the module boots fine. I can then re-insert the SD CARD and everything is fine until next time I flash.
>>> 
>>> So, something in the SD CARD itself is pulling down GPIO2, after flashing. That is D0, and very bizarre.
>>> 
>>> However, I think that is a workable compromise; we can’t flash with an SD CARD inserted.
>>> 
>>> I guess I can play around with the pull-up resistor size on D0 to see if I can improve on this, but I’m willing to live with that compromise.
>>> 
>>> So, it is working now on breadboard in 1 line mode.
>>> 
>>> I’m now going to move on to trying to get it to work with our external SPI flash arrangement, and 1 line mode. I have a breadboard already setup for that - just some re-wiring to be done.
>>> 
>>> If that works, I’ll try 4 line mode.
>>> 
>>> Onwards…
>>> 
>>> Mark.