Page 1 of 2
Re: ESP32 SRAM examples
Posted: Wed Oct 19, 2016 11:57 pm
by WiFive
Re: ESP32 SRAM examples
Posted: Thu Oct 20, 2016 1:49 am
by 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.
Re: ESP32 SRAM examples
Posted: Thu Oct 20, 2016 2:54 am
by WiFive
ESP_Sprite wrote: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.
Re: ESP32 SRAM examples
Posted: Thu Oct 20, 2016 4:34 am
by WiFive
dotthree wrote:ESP_Sprite wrote: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.
Re: ESP32 SRAM examples
Posted: Thu Oct 20, 2016 5:46 am
by WiFive
Re: ESP32 SRAM examples
Posted: Fri Oct 21, 2016 2:59 am
by 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.
Re: ESP32 SRAM examples
Posted: Fri Oct 21, 2016 1:37 pm
by WiFive
ESP_Sprite wrote: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?
Re: ESP32 SRAM examples
Posted: Fri Oct 21, 2016 5:43 pm
by hydrabus
WiFive wrote:ESP_Sprite wrote: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 ...)
Re: ESP32 SRAM examples
Posted: Sat Oct 22, 2016 4:01 am
by ESP_igrr
Existing bugs are being documented. As soon as that is finished and document is translated into English, it will be released.
Re: ESP32 SRAM examples
Posted: Mon Oct 24, 2016 12:35 pm
by comcat
ESP_Sprite wrote: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 ?