Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rudolph]

With adding even more stuff to my playground software I get higher error counts, with the display still up and running, reacting to touch.
Right now I see "Faults: 0 109" and this is after several minutes.

I don't know what the actual issue is with REG_DLSWAP not returning to 0 occasionally.
At 50 frames per second it is unlikely that this is an issue with my display list, the update runs through hundreds if not thausands of frames with no issue at all and then I blink and the counter is a increased a little.
And when I happen to observe the counter to increase there is no noticeable glitch, I can't even tell that it is skipping a frame.

I am not using the external flash right now and have this running on a BT815 based display with 800x480.
My buffer sits at 3721 bytes to be transferred over the SPI with DMA, this results in a display list that is 5116 bytes long.
I am using an ESP32-WROOM32 with ESP-IDF and the SPI is running at 16MHz for the display update, reading from the SPI is done with 10MHz.

I just removed the "return" from my REG_DLSWAP test and added saving and displaying the value that is not zero:

Code: [Select]

read8 = EVE_memRead8(REG_DLSWAP);
if(0 != read8)
{
  reg_dlswap_faults++;
  dlswap = read8;
// return;
}

I expected a failure when removing the "return" but it just keeps running.
And so far the only value that is returned from REG_DLSWAP is 2.

I modified the code to read REG_DLSWAP a second and a third time if the first read was not zero.
And displayed is:
Faults: 0 118
DL_SWAP: 2 0 0

Faults: 0 134
DL_SWAP: 2 2 2

I also observed
DL_SWAP: 2 2 0

I slowed down the SPI for reading the register to 4MHz and I am still seeing this.
Faults: 0 15
DL_SWAP: 2 0 0

So this is unlikely to be a glitch from reading the register and if it were there should be other values than just 0 and 2.
I reduced the speed for the display update down to 8MHz and counter still gets increased eventually.

I still don't know what this actually is, but so far it looks like the issue is with REG_DLSWAP in the BT815.
It sure looks like REG_DLSWAP is not always getting updated properly.

Faults: 0 262
DL_SWAP: 2 0 0

Code: [Select]

        read8 = EVE_memRead8(REG_DLSWAP);
        if(0 != read8)
        {
            dlswap2 = EVE_memRead8(REG_DLSWAP);
            reg_dlswap_faults++;
            dlswap = read8;
            dlswap3 = EVE_memRead8(REG_DLSWAP);
//            return;
        }

Faults: 0 347
DL_SWAP: 2 0 0

Faults: 0 354
DL_SWAP: 2 2 2

Faults: 0 411
DL_SWAP: 2 2 2

Faults: 0 435
DL_SWAP: 2 2 0

Faults: 0 439
DL_SWAP: 2 2 0

Faults: 0 531
DL_SWAP: 2 2 2

Faults: 0 537
DL_SWAP: 2 2 0

Faults: 0 616
DL_SWAP: 2 2 2

Odd.

It took a while to get there and it still keeps running with no issue.
And it is not constantly counting up, the value is stable for several seconds, then it ticks up
erratically untill it is stable again.

Faults: 0 702
DL_SWAP: 2 0 0

Faults: 0 783
DL_SWAP: 2 2 0

...

Faults: 0 3460
DL_SWAP: 2 0 0

....
And some readings several hours later:
Faults: 0 14407
DL_SWAP: 2 0 0

Faults: 0 14505
DL_SWAP: 2 2 2

Still going with no issue.

Time to switch to a different controller, the ESP32 is running too much software I have no control over.
Using the same display module and the same FFC I switched to one of my own boards that has an ATSAME51J19A clocked 80MHz.
The display loop is exactly the same, only the hardware abstraction changed for the SPI.
I directly went for 20MHz SPI clock after init.
The touch works just fine, so reading from EVE is not affected, usually this is the first to fail.

The "issue" is the same, REG_DLSWAP occasionally remains at 2 although EVE has about 17ms time to swap in the new display list after one
transfer is done before the next update is started.
And ignoring this does not stop the display from running.

Faults: 0 208
DL_SWAP: 2 2 2

Faults: 0 661
DL_SWAP: 2 0 0

Faults: 1965
DL_SWAP: 2 0 0

Faults: 0 1997
DL_SWAP: 2 2 2

[Maxzillian]

That's interesting that yours doesn't freeze up, despite seeming to exhibit similar behavior. I think when I get a chance I need to go through what has changed in your library since we branched from it and see if there's anything different in how everything is handled. I haven't had much time to observe it, but I do feel like migrating our images from RAM_G and the ARGB4 format to Flash and ASTC had a positive effect.

[BRT Community]

Hello,

I don't know what the actual issue is with REG_DLSWAP not returning to 0 occasionally.

I was curious on the above scenario and what the potential causes of REG_DLSWAP not returning may be so I liaised with the hardware team on this point.

They noted the following:

If the DL itself contains an infinite loop, then there is the potential for this to happen.
An infinite loop could be caused by a JUMP /CALL instruction, or if the display list contains no DISPLAY instruction.

It is also worth verifying any direct writes to RAM_DL as there is a possibility of errors occurring here and not being caught by the co-processor.

Best Regards,
BRT Community

[Rudolph]

They noted the following:

If the DL itself contains an infinite loop, then there is the potential for this to happen.
An infinite loop could be caused by a JUMP /CALL instruction, or if the display list contains no DISPLAY instruction.

It is also worth verifying any direct writes to RAM_DL as there is a possibility of errors occurring here and not being caught by the co-processor.

I have no JUMP / CALL instructions in my display list, DISPLAY is always my last command before CMD_SWAP and I never write to RAM_DL.

Maybe I am pushing a bit too hard, but not hard enough to actually break things.
I increased the time between display updates from 20ms to 25ms and after a while now the counter still sits at zero.
The frame rate for the panel is 73.89Hz.