ESP32-S3 LCD and I2S FULL documentation

Baldhead
Posts: 433
Joined: Sun Mar 31, 2019 5:16 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby Baldhead » Sat Apr 16, 2022 11:46 pm

@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
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby ESP_Sprite » Sun Apr 17, 2022 1:10 am

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
Posts: 433
Joined: Sun Mar 31, 2019 5:16 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby Baldhead » Thu Apr 28, 2022 10:33 pm

@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
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby ESP_Sprite » Fri Apr 29, 2022 1:21 am

That's octal ram, right? If so, DTR:
Quad PSRAM only supports STR mode, while Octal PSRAM only supports DTR mode.
(from here)

Baldhead
Posts: 433
Joined: Sun Mar 31, 2019 5:16 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby Baldhead » Fri Apr 29, 2022 2:09 am

ESP_Sprite wrote:
Fri Apr 29, 2022 1:21 am
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
Posts: 433
Joined: Sun Mar 31, 2019 5:16 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby Baldhead » Fri Apr 29, 2022 2:49 am

@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
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby ESP_Sprite » Fri Apr 29, 2022 5:58 am

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
Posts: 433
Joined: Sun Mar 31, 2019 5:16 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby Baldhead » Fri Apr 29, 2022 9:35 am

ESP_Sprite wrote:
Fri Apr 29, 2022 5:58 am
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
Posts: 8921
Joined: Thu Nov 26, 2015 4:08 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby ESP_Sprite » Fri Apr 29, 2022 12:12 pm

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
Posts: 433
Joined: Sun Mar 31, 2019 5:16 am

Re: ESP32-S3 LCD and I2S FULL documentation

Postby Baldhead » Fri Apr 29, 2022 3:34 pm

@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.
Attachments
ram.jpg
ram.jpg (14.05 KiB) Viewed 80129 times
ram_1.png
ram_1.png (74.83 KiB) Viewed 80129 times

Who is online

Users browsing this forum: No registered users and 83 guests