ESP32 SRAM examples

[WiFive]

http://esp32.com/viewtopic.php?f=5&t=19 ... Sram#p1246

Curious to know what SRAM chips you are considering?

[ESP_Sprite]

For now, you can use SRAM as a normal SPI device, optionally using DMA; that means you can basically only copy data from main memory to flash and back again. The ESP32 does have a facility where you can use external SPI SRAM as 'real' memory (you can malloc() a chunk of it and it essentially works the same as internal memory) but the current chip revision has a bug causing some reads of it to act up. We're preparing a new revision with that bug fixed, it should be on the market in two to three months.

You cannot run instructions from this external RAM, but that's not necessary: we can map flash in the same way so you can basically treat the external SPI flash as if it is internal memory to the ESP32. That way, you can execute code directly from flash. Esp-idf actually already works in this way: only code that also needs to be able to run if the flash is busy (eg during a write operation) is loaded into internal RAM.

[WiFive]

We're preparing a new revision with that bug fixed, it should be on the market in two to three months.

Approx how many devices will be affected and what will be the code for the new rev? Will be hard to tell if under a module shield.

[WiFive]

the current chip revision has a bug causing some reads of it to act up. We're preparing a new revision with that bug fixed, it should be on the market in two to three months.

To clarify is this a software/firmware issue or silicon issue?

Sounds like silicon. Maybe they can also take this opportunity to update the rom with the proposed full newlib option.

[WiFive]

Whats the newlib option?

https://github.com/espressif/esp-idf/is ... -253723520

[ESP_Sprite]

Sorry, isn't going to happen. Aside from the fact that this revision only involves one changed metal layer which I'm not even sure contains any ROM data, we need the software to be compatible with rev1, which means that the workarounds for the current chip have to be in esp-idf anyway.

[WiFive]

Sorry, isn't going to happen. Aside from the fact that this revision only involves one changed metal layer which I'm not even sure contains any ROM data, we need the software to be compatible with rev1, which means that the workarounds for the current chip have to be in esp-idf anyway.

Ah I was wondering how many mask layers would be affected. Any other bugs fixed in this spin?

[hydrabus]

Sorry, isn't going to happen. Aside from the fact that this revision only involves one changed metal layer which I'm not even sure contains any ROM data, we need the software to be compatible with rev1, which means that the workarounds for the current chip have to be in esp-idf anyway.

Ah I was wondering how many mask layers would be affected. Any other bugs fixed in this spin?

Do you have or do you plan to release an ESP32 Silicon Errata document ?
I think it is really mandatory to be transparent about such problem like all major manufacturer (TI, NXP, ST ...)

[ESP_igrr]

Existing bugs are being documented. As soon as that is finished and document is translated into English, it will be released.

[comcat]

For now, you can use SRAM as a normal SPI device, optionally using DMA; that means you can basically only copy data from main memory to flash and back again. The ESP32 does have a facility where you can use external SPI SRAM as 'real' memory (you can malloc() a chunk of it and it essentially works the same as internal memory) but the current chip revision has a bug causing some reads of it to act up. We're preparing a new revision with that bug fixed, it should be on the market in two to three months.

You cannot run instructions from this external RAM, but that's not necessary: we can map flash in the same way so you can basically treat the external SPI flash as if it is internal memory to the ESP32. That way, you can execute code directly from flash. Esp-idf actually already works in this way: only code that also needs to be able to run if the flash is busy (eg during a write operation) is loaded into internal RAM.

How to determine the chip is the old revision or the new revision ?