ESP32-S3 LCD and I2S FULL documentation

[Baldhead]

I'm having patience.

One week trying to solve that problem and nothing.

Most likely the problem is with the "ESP-IDF VS Code Extension".

I installed it on 2 different computers and the same problem.

And i'm not the only one using this vsc extension. It has more than 168 thousand downloads, is it just me having this problem ?

Solved by me.

https://github.com/espressif/vscode-esp ... issues/688

[Baldhead]

Cache is described in section 3 of the TRM, but here's the Cliffs Notes: There's a certain amount (configurable, I think 32 or 16K) of cache between the CPU and the PSRAM/flash. The idea is that if you access a byte in psram, the cache loads not only that byte but an entire cache line (32 or 64 bytes) in its RAM. If you then need to modify this byte, re-read it, or read the bytes that are next to it (e.g. a memcpy loop), the cache can handle these requests and you don't need to wait for the relatively slow flash or PSRAM bus.
Ok. I read section 3. I set instruction cache with 32K, 8 ways, 32 bytes and data cache with 64k, 8 ways, 64 bytes.

As cache is not of unlimited size, if it's full and you want to read new data, it needs to 'push out' old data. For flash data (which is seen as read-only), the cache simply throws it away, but for PSRAM data that has been modified (the term is that the cache line is 'dirty'), it needs to write back the cache line to PSRAM entirely.
OK.

Now, this mostly works entirely transparent; if all you use is the CPU to access PSRAM, you never have to worry about the cache; while there may be a discrepancy between what the CPU sees and what is actually in the PSRAM, the CPU can't access the PSRAM directly anyway, so who cares, right?
OK.

This changes when you start doing DMA from PSRAM. DMA accesses PSRAM directly, not through the cache. While this may initially sound stupid, there's a good reason for it: for instance, if you were to use PSRAM to store audio data to send to an I2S device and that would happen through the cache, the wave data would need to be read into the cache, only to be used exactly once, so the cache doesn't give you any real benefit... but at the same time, it would 'push out' data that probably would be useful to have in cache, so the net performance would be diminished by a lot.
OK.

So what you probably ran into is the following: you write a chunk of data that is many times the size of the cache. This means the cache fills up a few times, and when more than the size of the cache is written, every new write triggers a writeback of the old data. That happens all the way up to the final byte, at which state everything except what's currently in the cache (the last 5%, as you said?) is written back. Then you start up DMA, and all the data is read correctly... except for the last 5%, as it's still hanging around in the cache and never made it back to the PSRAM.
The problem is not quite that 5%, i already reduced the size of the buffer and it even got worse. Already decreased the clock of the i8080 bus to 1 Mhz and the problem persists.

So, as I said, Cache_WriteBack_Addr solves this, as it forces a writeback of all data in a certain range. You call it with the starting address and the size of the buffer you wrote, and then the cache goes to work and sees if there's anything in that range that needs to be written back. From what I can tell, the call is blocking, so after it returns you can be sure the data made it to the PSRAM.
I am using Cache_WriteBack_Addr() in the entire buffer after i write in the buffer.
Are you sure this function is blocking ?

The reason that all the calls in that file are marked as 'do not use in the SDK' is that caching functions generally are a bit finnicky with regards to interrupts and multicore operation... while writeback is pretty innocuous, you also have functions like 'clean' (act like a cache line never has been written to) and 'invalidate' (throw away a cache line without writing it back). You can probably imagine that those ops can lead to data loss if one core does them while the other core is working on something in the same memory region. We still need to figure out how we can make these caching functions more accessible (as they're pretty useful if you want to speed up operations). For now, feel free to assume at least the writeback function is safe.
OK. I am using this function.

Does that make it understandable why you're getting the results you're getting?
Yes. Thank you for the explanation.

[Baldhead]

Hi @ESP_Sprite,

Development board: ESP32-S3-DevKitC-1-N8R8.

If i send only one pixel(two bytes) using "edma", the value is correct at i80 bus.

If i send a bigger buffer start giving problem.
I will test and try to find a stable buffer size.

is there a maximum buffer size to work with edma ?

For example: I allocated a buffer with 307200 bytes and sent 200 000 bytes.
I change only the firt pixel to 0x1234.

The first 2 bytes apparently it's ok(i will measure), the third byte get corrupted and the final of "packet" gets corrupted too.

Code: Select all

for( uint32_t i = 0 ; i < 153600 ; i++ )  // 1 pixel = 2 bytes
{
    p_buffer_a[i] = 0xffff;
}

p_buffer_a[ 0 ] = 0x1234;  // PSRAM send first least significant byte(0x34) then send most significant byte(0x12).

// CPU writes data to PSRAM through DCache, data in PSRAM might not get updated, so write back
//Cache_WriteBack_Addr( (uint32_t)&p_buffer_a[ 0 ], 1 )
int ret = Cache_WriteBack_Addr( (uint32_t)p_buffer_a, 153600 );
printf("\n\nret = %d\n", ret);

Thank's.

[Baldhead]

Hi @ESP_Sprite,

Development board: ESP32-S3-DevKitC-1-N32R8V

TEST_1:
Allocated buffer: 307200 bytes.
Sent bytes: 307200 bytes.

Test Results:
Only final of "packet" gets corrupted.

Code: Select all

 #define pixels_size 153600  // 1 pixel = 2 bytes

for( uint32_t i = 0 ; i < pixels_size ; i++ )  
{
    p_buffer_a[i] = 0xffff;
}

p_buffer_a[ 0 ] = 0x1234;  // PSRAM send first least significant byte(0x34) then send most significant byte(0x12).

int ret = Cache_WriteBack_Addr( (uint32_t)p_buffer_a, pixels_size );
printf("\n\nret = %d\n", ret);

TEST_2:
Allocated buffer: 307200 bytes.
Sent bytes: 200000 bytes.

Test Results:
Sometimes it works, sometimes it doesn't work.
When it doesn't work, it looks like that problem( https://www.esp32.com/viewtopic.php?f=5 ... =60#p91835 ).
LCD_CAM.lcd_misc.lcd_bk_en = 1; // BUG mode intel 8080 bus !!!!!
Attached images.

Code: Select all

 #define pixels_size 153600  // 1 pixel = 2 bytes

for( uint32_t i = 0 ; i < pixels_size ; i++ )  
{
    p_buffer_a[i] = 0xffff;
}

p_buffer_a[ 0 ] = 0x1234;  // PSRAM send first least significant byte(0x34) then send most significant byte(0x12).

int ret = Cache_WriteBack_Addr( (uint32_t)p_buffer_a, pixels_size );
printf("\n\nret = %d\n", ret);

[Baldhead]

@ESP_Sprite,

It seems that the i8080 with 8 bit bus clock limit, when using gdma with psram, is something close to 20 Mhz.

When i set LCD_CLK = 40 Mhz and LCD_PCLK = 20 Mhz, apparently the buggy second clock problem disappears.

A strange thing i noticed:
Allocated buffer: 400 000 bytes.
Sent bytes: 307 200 bytes.
All OK !!!!!

When i allocate X memory bytes and send X bytes the end of the transmission is corrupted.
From what i realized, i need to allocate more memory than i am sending for the problem not to happen.
Why ???
Could it be that the memory allocation is incorrect ?

[Sprite]

At least one issue is that your

Code: Select all

int ret = Cache_WriteBack_Addr( (uint32_t)p_buffer_a, pixels_size );

seems incorrect: pixel_size is the size of your array of (16-bit) pixels, but the Cache_WriteBack_Addr function needs the amount of bytes, so you're writing back only the first half of the array.

[Baldhead]

At least one issue is that your

Code: Select all

int ret = Cache_WriteBack_Addr( (uint32_t)p_buffer_a, pixels_size );

seems incorrect: pixel_size is the size of your array of (16-bit) pixels, but the Cache_WriteBack_Addr function needs the amount of bytes, so you're writing back only the first half of the array.

woooo, what a stupidity of mine, thank you.
Worked.

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

It seems that the i8080 with 8 bit bus clock limit, when using gdma with psram, is something close to 20 Mhz.
With 24 Mhz the "packet" is sent once correctly and then the gdma/lcd_cam hangs.
Could you confirm this for me ?

Bug esp-idf/vsc extension again out of nowhere.
https://github.com/espressif/vscode-esp ... issues/688

[Sprite]

I can't confirm it personally, but a colleague who wrote our LCD driver tells me that the interface indeed works up to 20MHz or so in his experience. I'll see if I can get some explanation from a colleague in the digital team, but given the lockdown here in Shanghai, I can't tell you when I expect to receive an answer.

[Baldhead]

@ESP_Sprite,

Could you help me with this ?
Two weeks already.

https://github.com/espressif/vscode-esp ... 1188916653

[Baldhead]

@ESP_Sprite,

Could you help me with this ?
Two weeks already.

https://github.com/espressif/vscode-esp ... 1188916653

Solved.