ESP32 Forum

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.

I decremented the lcd bus frequency to 15 MHz and it worked with the server enabled.
I don't know if this frequency is stable, i also don't know if the data sent to the lcd is correct because the lcd bus is not connected to the lcd "glass" yet.

Do you have some point about this "bandwidth starvation" ?
Or maybe digital team ?

I'm sure we have or will have some docs online for that at some point, I seem to remember a colleague was working on them, but the skinny of it is that PSRAM access is roughly divided 50%/25%/25% between DMA, CPU0 and CPU using a round-robin arbiter (so the percentages of the others can grow if one doesn't use up the full bandwidth). This means that if you happen to configure all EDMA peripherals in such a way that it uses more than 50% of the bandwidth, you will be okay... but only up to the point that the CPUs decide they need to access lots of PSRAM. Unfortunately, the S3 peripherals don't react well to being data starved on the DMA, and stuff falls apart.

(Btw, I've partially worked around this issue myself by using a bounce buffer in internal memory to DMA out from and use the CPU to copy data from PSRAM to internal memory... it's not as nice and somewhat CPU intensive, but as the internal memory doesn't have the bandwidth limitation, it tends to work better at rates at or over the allocated DMA speed limit.)

Hi @ESP_Sprite,

I enabled ecc on psram.

Will it influence in some way ?

Thank's.

ESP_Sprite wrote: ↑

Wed May 04, 2022 5:17 am

I'm sure we have or will have some docs online for that at some point, I seem to remember a colleague was working on them, but the skinny of it is that PSRAM access is roughly divided 50%/25%/25% between DMA, CPU0 and CPU using a round-robin arbiter (so the percentages of the others can grow if one doesn't use up the full bandwidth). This means that if you happen to configure all EDMA peripherals in such a way that it uses more than 50% of the bandwidth, you will be okay... but only up to the point that the CPUs decide they need to access lots of PSRAM. Unfortunately, the S3 peripherals don't react well to being data starved on the DMA, and stuff falls apart.

(Btw, I've partially worked around this issue myself by using a bounce buffer in internal memory to DMA out from and use the CPU to copy data from PSRAM to internal memory... it's not as nice and somewhat CPU intensive, but as the internal memory doesn't have the bandwidth limitation, it tends to work better at rates at or over the allocated DMA speed limit.)

There is also the problem of the cpu accessing the flash memory that uses the same bus as the psram.

This bounce buffer kind of eliminates the advantage of using dma.

Hi @ESP_Sprite,

With ecc disabled on psram i reach 20 MHz on lcd bus.

I don't know if all the transmitted information is correct, but the packet transmission time is correct.

@ESP_Sprite,

I decided to replace a flag with a binary semaphore, ie: xSemaphoreCreateBinary(), to guard GDMA busy channel.

When i used the flag(the flag was released on dma end of transfer interrupt), sometimes the flag was not released, and task locked on not released flag, triggered the watchdog after 5 seconds.

So i thought of using a binary semaphore to reset the dma channel crashed and maybe the esp32-s3 lcd module crashed too.

What i noticed is that after the binary semaphore timeout, the hardware recovers itself without me doing anything, ie, after setting a new dma transaction, the new transaction worked.

From time to time the semaphore generates timeout, it works a little, then generates timeout and so on.

So......

I think that dma interrupt are not triggering sometimes and does not release the semaphore inside the interrupt with "xSemaphoreGiveFromISR(hw_lcd_dma_binary_semaphore, NULL)".
I thought the hardware crashed and only resetting the esp32-s3 would make the system work again.

Why interrupt are not firing sometimes ?
Maybe a "outlink descriptor's FSM" bug or some other configuration i need to do in the system.

Thank's.

Hello Baldhead,

i really really need your help
Actually i have a ESP32 and im sending 24Bit data parallel with I2S. But the ESP32 has not enough pins and not enough space for my data. Now i bought a ESP32S3 because of more pins and more space.
I thougt i can use it out of the box, but there are a lot of changes.

Actually i use a I2S library like this: https://github.com/TobleMiner/esp_i2s_parallel
Have you any help for me how i can change it to the ESP32S3

Many many thanks!

Tobi82m wrote: ↑

Wed Jul 06, 2022 10:07 am

Hello Baldhead,

i really really need your help
Actually i have a ESP32 and im sending 24Bit data parallel with I2S. But the ESP32 has not enough pins and not enough space for my data. Now i bought a ESP32S3 because of more pins and more space.
I thougt i can use it out of the box, but there are a lot of changes.

Actually i use a I2S library like this: https://github.com/TobleMiner/esp_i2s_parallel
Have you any help for me how i can change it to the ESP32S3

Many many thanks!

Based on everything that is writen in the documentation so far the maximum parallel output witdh that the S3 supports is 16 bit via the LCD module.

Oh, really? So there is no chance to send 24 Bit (32 Bit) parallel with 1-2 MHz?
I had use a ESP32, it can work with 24 Bit, but have not enough pins. So i think to work with a ESP32S3. Additionaly i want to use the PSRAM for bigger data streams stored in a array. Any other Ideas?

Tobi82m wrote: ↑

Fri Jul 08, 2022 5:28 am

Oh, really? So there is no chance to send 24 Bit (32 Bit) parallel with 1-2 MHz?
I had use a ESP32, it can work with 24 Bit, but have not enough pins. So i think to work with a ESP32S3. Additionaly i want to use the PSRAM for bigger data streams stored in a array. Any other Ideas?

maybe using i2s module of esp32-s3.