Just a thought, what is your SPI clock and have you tried to reduce it while reading?

In my experience, writing to EVE works a whole lot faster reliably than reading does.
And then there is driving the lines thru at least two connections of a FFC, depending on the layout,
the host mcu and the settings for the pins, SPI_CLK might not be looking so good and there might be reflections.

Hello,

Thank you for your question.

Can I ask how you have configured the interrupts?

Would it also be possible to provide a logic analyser capture of a read of the flags register when the issue occurs?

The interrupt flags not returning as expected is curious, but it would not be considered a fault scenario on its own.

Just to clarify you would only need to perform a fault recovery if the REG_CMD_READ register reports a value of 0xFFF (indicating a fault in the co-processor). In terms of EVE and the touch engine, the current valid display list contained within RAM_DL, will be read by the touch engine for tagged items, which will then updated the REG_TOUCH_TAG register if an item has been touched accordingly. In this sense as you have noted your screen manager is out of sync with what it believes to be on the screen, what is the mechanism, that you are using to keep track of screens in your application?

Best Regards,
BRT Community

[Originally posted to FTDI Community; was directed to move post to here]

We have a system using the FT813 display controller with a Newhaven display and capacitive touch screen.  At startup, the firmware configures the FT813 to enable touch tag changed interrupt and the swap complete interrupt, so the flags enabled are 0x05.  The main screen of the application updates every 100 ms.  Logic analyzer traces show the interrupt input from the FT813 to the host microcontroller going active, followed by the host firmware reading the interrupt flags.  Ordinarily this works fine, and the FT813 reports SWAP complete after the screen contents have been delivered to the command coprocessor and the swap command is executed and completed.  (Incidentally, Command FIFO Flag / CMDFLAG is also set.)

Intermittently, though, the interrupt flags returned are 0x4A, which indicate sound effect ended and touch detected, but the application does not use sound, the screen is not being touched, and none of these interrupts were enabled by the host firmware.  The timing of the interrupt is the same as if the screen swap has actually completed, but the swap interrupt flag is not set, so the application is not sure it's safe to write a screen update, and does nothing in response to that interrupt.  At this point in the evolution of this application, it just times out and resumes writing updates to the command coprocessor, and everything proceeds normally for a while, but this condition does pop up from time to time.

In earlier application firmware versions, it was (needlessly) rewriting the screen contents to the command coprocessor as soon as the swap was complete.  With this firmware, these errant interrupt flags were reported intermittently, but much more frequently.

My question is whether this indicates some sort of fault condition not listed in the documentation.  There are scenarios where screen content could actually change every 100 ms, so we would like to keep the capability of using this update frequency.  If the application sees this condition, should it go through the fault recovery procedure?

This does not cause a problem if the main screen is just sitting there updating with no user interaction, but when navigating from the main screen and between any of the other screens, the device can eventually stop responding to touch.  I have found that at least one cause of this is that the FT813 thinks one screen is displayed, while the screen manager in the application thinks it has moved to a different screen.  Touch interrupts are occurring, but the touch tag belongs to the wrong screen from the screen manager's perspective.  I'm wondering if this interrupt flag issue could be a cause for the application to get out of sync with the display controller, and so the application needs to treat the invalid interrupt flags as a fault condition.

Time for some torture-testing of the BT820. :-)

The attached image shows this code:


        int16_t xc0 = 0;
        int16_t yc0 = 0;
        uint16_t length = 3;
        static uint16_t increase = 0;
        uint32_t colors[] = {RED, ORANGE, GREEN, BLUE, YELLOW, MAGENTA, PURPLE, BLACK, 0xc0c0c0, BLUE_1};

        for(uint8_t arms = 0; arms < 12; arms++)
        {
            EVE_color_rgb(colors[arms]);
            EVE_begin(EVE_LINE_STRIP);
            for(uint8_t steps = 0; steps < 135; steps++)
            {
                EVE_polar_cartesian(length*steps, arms*30+steps*increase, &xc0, &yc0);
                EVE_vertex2f(xc0 + 450, yc0 + 320);
            }
            EVE_end();
        }

        static uint8_t delay = 0;

        delay ++;

        if(delay > 2)
        {
            delay = 0;
            increase += 3;
        }


12 Linestrips with 135 segments each, 6916 bytes in the SPI buffe, a display-list of >8100 bytes, takes 1.3ms to preprare the buffer.
And this runs continously now, changing constantly.

All I noticed was that it started to flicker when I increased the "steps" in the loop.
Not for every value of "increase" though.
The flickering goes away when I decrease the maximum "steps" or increase the time between display-list updates.
Right now I am running this as posted and refresh the display list every 75ms, so 13 changes per second.
So this put the render-engine into stress-mode, sort of.

Nice, this stupid level of useless complexity should be way beyond what a normal application can put out to render. 

Some might have noticed it already, I uploaded a new library on Github: https://github.com/RudolphRiedel/EmbeddedVideoEngine
I had the idea of renaming my library for a while, "FT800-FT813" was just wrong for a while now.
However, renaming seemed to be a bit disruptive, so I created a new repository for V6 of my library and the name should be future-proof now. :-)
I was already using the name for a while now in the library.json for PlatformIO.

Yesterday I tested the Arduino example, made sure it compiles for all tagets (although a few are non functional like the one for BBC Microbit.
And then I tested ESP32-S2, Arduno UNO V3, Teensy 4.1, Raspberry Pi Pico and Metro M4 with both a RVT50H (BT817) and the VM820C.

Right now I have the VM820C with the 7" 1024x600 TFT up and running with an ATSAME51 after a fix to the DMA code, and I already checked it with a BT817.
As usual, no warnings with -Wall -Wextra -pedantic.

Before I was using a STM32F407, so most targets are covered by now, at least are compiling or actually are tested.

While the lib is feature complete for the BT820, this is not finished.
There are still a couple of things missing like configuring the memory size for the BT820, the LVDS output clock is merely working by chance now, Audio does not seem to be working at all, video input is unexplored...

Unfortunately there are no modules for sale with a BT820, as far as I know. And only one was anounced.

I also learned again that sourcing LCDs is still a major pain, these things are really not commodities, speaking of course for not buying in bulk from a company account, trying to aquire single units.

I implemented CMD_LOADWAV and in order to test it I enable audio in BOOTCFG.
The screen stays black though.

The host command is correct, it changes from 0xff 0xe8 0xc0 0x00 0x00 to 0xff 0xe8 0xe0 0x00 0x00.
Things look normal on the logic analyzer, "only" the screen stays black.

I am not writing to any of the audio registers, including not using CMD_LOADWAV.
I even moved the buffers for the swapchains.

Is it possible that the audio engine is messing with the clock tree?

I implemented a couple more commands and got to CMD_WATCHDOG.

Quote
The watchdog command enables the watchdog timer and sets the watchdog reset intervals in clocks.
The watchdog flag in REG_BOOT_CFG register must be set.

C prototype
void cmd_watchdog ( uint32_t init_val );

Command layout
+0 CMD_WATCHDOG(0xFFFF FF83)
+4 init_val

Parameters
init_val
Watchdog timeout initialization value, in clocks. Must be a sensible value to prevent
watchdog being triggered prematurely.

Examples
To set the watchdog timeout every 72000000 clocks, which is 1 second on a 72 MHz system:
cmd_watchdog(72000000);

Quote
Adds watchdog timer to facilitate automatic correction.

Quote
The watchdog timer uses a 32-bit counter and is driven by the system clock. Hence, at default system
clock of 72 MHz, the maximum timeout period supported is 59.6s.
The watchdog timer begins and resets as it counts down from a user-defined initial value. Upon reaching
a count value of zero, the watchdog timer generates a system reset. The timer needs to be periodically
reset to the initial value to prevent the system reset from happening.
Refer to BRT_AN_086 BT82X Series Programming Guide for details on how to program the Watchdog
Timer using cmd_watchdog

That is practically all if it.
So yes, the watchdog system needs to be enabled during boot.
And it does a system reset - whatever "automatic correction" this is good for.
Then there is CMD_WATCHDOG which is documented to enable the watchdog and configure the timeout.
But there is no command like CMD_TRIGGER_WATCHDOG, so CMD_WATCHDOG is resetting the timer?

And if CMD_WATCHDOG really is the only command, does a CMD_WATCHDOG(0) disable the watchdog?

What safety requirements are covered by this?
If the EVE chip would crash hard, and I never encountered this, would the watchdog timer really not be affected?
And how would a reset help in this scenario? The host controller had to detect either way that the EVE chip is not answering anymore.
Ok, different scenario, the host controller crashes, how would resetting the EVE chip help? The host controller would still be dead.
So when the watchdog is not triggered by CMD_WATCHDOG, the screen goes dark?

What am I missing here?
If the EVE chip would be able to reset the host controller, that would be different, that would make the EVE chip an external watchdog controller and that could  be viewed as positive for the system safety.
But I would use a window-watchdog with challenge-response for such a task, preferably in a SBC.

Nice work Rudolph! Your application looks great and good to see you've got the SD card running,
Yes, the longer RAM_DL is a nice thing to have on the BT820B to support larger amounts of text etc.

Best Regards, BRT Community

Another day, another screen of progress. :-)

I just added CMD_LOADASSET and tried it with two fonts converted with EAB 3.0.
Loading from SD card is really nice.

I am wondering what is driving up the display-list so much.
EVE_cmd_cgradient(EVE_EDGE_ZERO, 300, 200, 200, 200, WHITE, PURPLE); - 140 bytes
EVE_cmd_arc(400, 300, 100, 110, 0, 16384); - 144 bytes
debug-output of 8 hex-numbers - 736 bytes

Ok then, most of it is for all the text.

QuoteOne way to check is to perform a cmd_fssize.  Directories will return -1 for the size.

Well, yes and no, technically. :-)
The size is documented to be a uint32_t.

And I got a couple of steps further along now, my test code is using CMD_FSSOURCE, CMD_LOADIMAGE with OPT_FS and CMD_GETIMAGE
to load one of the files returned by CMD_FSDIR and then display it.
I also found OPT_TRUECOLOR during this.