ESP32-S3 LCD and I2S FULL documentation

[Baldhead]

@ESP_Sprite,

Sorry for the insistence, but i will need this information when to write graphical driver.

"I am using Cache_WriteBack_Addr() in the entire buffer after i write in the buffer.
Are you sure this function is blocking ?"

Thank's

[ESP_Sprite]

Sorry, I meant to look that up for you but it slipped my mind.
Last line of the code in ROM is

Code: Select all

while(!REG_GET_BIT(EXTMEM_DCACHE_SYNC_CTRL_REG, EXTMEM_DCACHE_SYNC_DONE));

so yeah, I'm pretty sure it's blocking.

[Baldhead]

@ESP_Sprite,

Could you tell me if the psram memory inside esp32-s3 package is str(single transfer rate) or dtr(double transfer rate) ?

* ESP32-S3R8
* ESP32-S3R8V

Thank's.

[ESP_Sprite]

That's octal ram, right? If so, DTR:

Quad PSRAM only supports STR mode, while Octal PSRAM only supports DTR mode.

(from here)

[Baldhead]

That's octal ram, right? If so, DTR:

Quad PSRAM only supports STR mode, while Octal PSRAM only supports DTR mode.

(from here)

Thank's

[Baldhead]

@ESP_Sprite,

i am still investigating a problem with gdma crashing, but, maybe you can help me.

Initial context:
I was setting dma channel without using esp-idf lib(gdma.h), something like that, i am on cell phone now, gdma_new_channel().
I was directly allocating channel 0 without use gdma.h.
while i was testing only gdma with lcd everything was ok, but when i enabled esp_https_server, the data at lcd bus bugged.
Fortunately, i supposed that esp_https_server was using aes e sha along with gdma, and after some tests, i was able to confirm my assumption.
So i used the gdma.h lib to allocate a gdma channel that was available, and apparently it solved this problem.

continuing......

Apparently using psram alone with gdma to transfer data to the lcd peripheral is ok.
When i enabled graphical lib, the gdma crashed.
I think because i am using double buffering, ie, when one buffer is being transferred by gdma, the other buffer is being rendered.
I tested with sram and it worked.
The problem appears when i use psram.

Could it be that the psram cannot be written while gdma is reading the psram ?
Some cache problem with psram or maybe with the flash memory ?

Note: i disabled function Cache_WriteBack_Addr() to test, but it didn't work either.

Code: Select all

static esp_err_t hw_lcd_dma_allocate_dma_channel_to_lcd_cam_peripheral(uint32_t* allocated_channel)
 {
     int channel_id;
     esp_err_t ret;   
     gdma_channel_handle_t dma_chan;  // DMA channel handle
 
     gdma_channel_alloc_config_t dma_chan_config = 
     {
         .direction = GDMA_CHANNEL_DIRECTION_TX,
      };
 
     ret = gdma_new_channel(&dma_chan_config, &dma_chan);
     if(ret!=ESP_OK) return ret;
 
     ret = gdma_get_channel_id(dma_chan, &channel_id);
     if(ret!=ESP_OK) return ret;

     *allocated_channel = channel_id;
 
     hw_lcd_dma_set_dma_channel(*allocated_channel);
    
     return ESP_OK;
 }

[ESP_Sprite]

Are you sure you're not running into a bandwith problem? It seems like the LCD PSRAM stuff is pretty sensitive to bandwidth starvation and doesn't really handle it well.

[Baldhead]

Are you sure you're not running into a bandwith problem? It seems like the LCD PSRAM stuff is pretty sensitive to bandwidth starvation and doesn't really handle it well.

How can i test this ?

I will try to decrease the frequency of the LCD bus.

Note/suggestion:
If psram die is internal to chip esp32-s3(probably on top of esp32-s3 die), why didn't espressif connect the psram directly to the internal bus of the esp32-s3 without having to go through the cache ?
Could have used a much larger bus width too(separated address and data buses).
Could be connected similar to bga, i think today it is connected via wire bonding.

Another possibility that I had already said before espressif released the new chips, was to use separate buses to access flash and psram memory with flash and psram caches totally separate, maybe with quad io dtr to save io.

But the first suggestion seems better to me, use external flash octal dtr and psram connected directly to the esp32-s3 die bus(possibly with separate internal buses like bus matrix of microchip competitor).

[ESP_Sprite]

For a very stupid physical reason. If we were to use a chip with a larger bus (say, a DDR3 die), the RAM die itself would also be bigger because pads take up space. If the RAM die is too big, it overlaps the entire S3 silicon and we can't lay the bond wires anymore. (I know this because I proposed something similar internally at some time; it's actually an issue.) Separate buses for flash and PSRAM is something we did think about, as well as other weird solutions like interleaving multiple PSRAM chips. That tech did not make it into the ESP32S3, though.

(Note that even with that, you would still need cache. Non-cache DRAM generally has very good general speeds, but the latency is horrible. That is, if you read or write one byte, the setup time would be exactly the same as if you were to read in an entire cache line. For direct access, that is no cache, the setup time for the 1 to 4 bytes the CPU can access would be way larger than the time to read those bytes. We can bypass cache for DMA as generally DMA reads large regions of RAM in a sequential fashion, so we can safely read a large chunk into a FIFO and be pretty sure the data is actually used.)

[Baldhead]

@ESP_Sprite,

I believe that using a second sram die would also be a problem, but here's a suggestion.

As sram takes up more space on the die than psram(dynamic ram), the memory size could be reduced, 2MiB or 4MiB for example.

Direct connection to esp32-s3 address and data bus without cache (maybe a large data bus) with through-silicon via (TSV) and microbumps.

Obviously espressif have to consider the cost issue of this TSV technology.