Update 64MB Flash on EVE4

[cvu1]

Hi All,

I'm working on updating EVE4 display Flash from TM4C MCU using 16Mhz SPI. I'm currently using Riverdi EVE4 7" display that comes with 64MB of flash.

What my code is doing now is:

1. Check if Flash is empty or not. If it is not empty, erase it.

2. Install Blob to flash by:

   =============================================
   for (j = 0; j < 4096; j++){
   Gpu_Hal_Wr8(phost, RAM_G_Address, Blobdata[j]);
   RAM_G_Address++;
   }
   RAM_G_Address = 0;
   // Copy from 4K data from RAM_G starting address 0 to Flash at address 0 with 4k bytes
   Gpu_CoCmd_FlashUpdate(phost, Flash_Address, RAM_G_Address, 4096);
   Gpu_Hal_WaitCmdfifo_empty(phost);

3. Switch the Flash to SQPI mode and then fill the rest with dummy data using Wr8 command for testing.

This method takes about 20 minutes to fill 64MB.

The EVE Asset Builder tool takes about 9 minutes to update the flash.

How do I improve the writing time? I'm thinking about using Wr32 command but not sure it will help.

Has anyone dealt with this problem before and how did they solve it?

[RudolphRiedel]

Yes, using individual wr8 commands to transfer bytes to RAM_G takes a long time as there is always 3 bytes address overhead.
CMD_FLASHUPDATE requires 4096 byte blocks, so that is 12288 bytes overhead. Using wr32 reduces this to 3072 bytes.
I do have a block transfer function though: EVE_memWrite_sram_buffer() - 3 bytes overhead for the whole buffer.

But to take that a step further, CMD_FLASHUPDATE has to take extra steps and your flash is empty anyways.
What you want to use in this case is CMD_FLASHWRITE which writes directly from RAM_CMD and works pages of 256 bytes.
I have a function for this as well which includes sending the buffer, executing the command and waiting for completion:
void EVE_cmd_flashwrite(uint32_t ptr, uint32_t num, const uint8_t *p_data)

Hmm, as RAM_CMD is only 4k in size I do wonder now what happens if EVE_cmd_flashwrite() is used with more than 4k.
It is possible that pages are written to the flash while data keeps incoming, at least there is no warning in the programming guide that "num" must not exceed 3840 bytes to not overflow the RAM_CMD FIFO.
How long does writing a page in a flash take?
Transferring a page to the flash over the QSPI should take maybe 20µs.
Writing a page depends on the flash chip, I opened two datasheets now and the first had 0.75ms max and the second had 3ms max.
Hmm, the transfer of a page to the BT817 should take not less than the page write time, at 3ms this would mean to clock the SPI with 680kHz to go without limit.
At 0.75ms this is 2.7MHz.
If that is true then the better idea probably is to do transfers of a maximum of 3840 bytes and wait for the operation to finish.
Ok, 4096 might be working as well even at 16MHz for the SPI as this are 16 pages and the first page that gets overwritten with page 16 only needs to be transferred to the flash before it gets overwritten.
I guess I have another test scheduled for tomorrow. :-)

What is the point of this exercise though?
Some kind of end-of-line flash updater that operates stand alone and takes an image fron a sd card?

[cvu1]

Hi Rudolph,

What I'm doing is for Firmware Update. PC send data to MCU, and write to Flash. What will be the best wait to implement this? Currently, I'm write 4096 Bytes to RAM_G. How to get this to RAM_CMD to use with EVE_cmd_flashwrite?

[cvu1]

   if(i == 0){

       UARTprintf("Start first half blob \r\n");
       Gpu_CoCmd_FlashWriteExt(phost, Flash_Address, 2048, arr1);
       App_Flush_Co_Buffer(phost);
       Gpu_Hal_WaitCmdfifo_empty(phost);

       Flash_Address += 2048;
       UARTprintf("Done first half\r\n");

   } else if (i == 1){

       Gpu_CoCmd_FlashWriteExt(phost, Flash_Address, 2048, arr2);
       Gpu_Hal_WaitCmdfifo_empty(phost);

       Flash_Address += 2048;

       Gpu_CoCmd_FlashHelper_SwitchFullMode(phost);
       UARTprintf("EVE Display Flash in SQPI Mode\r\n");
   }

Some how Gpu_Hal_WaitCmdfifo_empty(phost); never pass. Stuck in while(Gpu_Hal_Rd16(host,REG_CMD_READ) != Gpu_Hal_Rd16(host,REG_CMD_WRITE));. Not sure why.

[RudolphRiedel]

How to get this to RAM_CMD to use with EVE_cmd_flashwrite?

Either use my function from my library directly or use it as a template to implement this in the library you are using.

Some how Gpu_Hal_WaitCmdfifo_empty(phost); never pass. Stuck in while(Gpu_Hal_Rd16(host,REG_CMD_READ) != >Gpu_Hal_Rd16(host,REG_CMD_WRITE));. Not sure why.

This is something I would check with the logic-analyzer, it might be either a hardware issue or a driver issue.
I have no idea what Gpu_CoCmd_FlashWriteExt() might be doing.

What I'm doing is for Firmware Update. PC send data to MCU, and write to Flash. What will be the best wait to implement this?

Probably not implementing this and using one of the existing implementations.
Like the one from Bridgetek for the RP2040: https://github.com/Bridgetek/pico-brteve/tree/main/tools/uf2

But well yes, CMD_FLASHWRITE should be the fastest way to fill the flash.
The flash on the Riverdi modules likely is a MT25QL512.
The datasheet list "Page program time (256 bytes) " as 120µs typ (50% 0 bits) and 1800µs max.
64MiB are 262144 pages, so programming the pages alone takes between 32s and 472s.
The transfer from PC to µC, from µC to EVE and from EVE to the chip will take the rest of the time.
The TM4C "only" do USB FS, so 12Mbit/s by itself, HS with an extra chip.
Still, transferring a page of 256 bytes should be much faster than 120µs.
TM4C even supports QSPI, but even a 16MHz single SPI should be faster than the USB when used with low overhead.
With two buffers of 2048 bytes to allow for USB transfers while data is transferred by SPI to EVE the system should still end up waiting for the pages to be programmed.
It might help a little to use as many buffers as possible, but the effort spent is probably not worth the time saved on transfers.

And yes, of course, I might be completely wrong on this as a whole, this is just me playing this out as a thought experiment.
If I am wrong though, I would like to be corrected. :-)

[cvu1]

@RudolphRiedel

I tried to understand your EVE_execute_cmd() now.
I'm currently using the Riverdi EVE4 API (https://github.com/riverdi/riverdi-eve-arduino).

Look at Bridgetek example, they calls EVE_Cmd_waitFlush(s_pHalContext); after swap called (https://github.com/Bridgetek/EveApps/tree/master). However, Riverdi doesn't call after swap functions get called.

But I do note that they call Gpu_Hal_WaitCmdfifo_empty(phost); in Gpu_CoCmd_FlashHelper_Write or other CoCmd functions. I guess this is same as waiting for Cmd FIFO to finished and empty.

Also, I see you use EVE_Busy to check the Cmd FIFO.

All three is use to make sure the Co-Op Processor Complete Execute cmd in cmd fifo without error. But all three done in difference way.

Have you ever use the Bridgetek or Riverdi API and get any problem so you come up with your own EVE_Busy function?

As I said I have a problem with Gpu_Hal_WaitCmdfifo_empty(phost); that stuck when writing data to EVE4 Flash. I'm looking for better way to handle this issue.

[RudolphRiedel]

The original FTDI implementation was the reason why I started with my library back in end of 2015.
And since then I have not actively used any other implementation.

The main difference between the implementations is that the Riverdi and the Bridgetek version still use the old FT80x API, they write directly to RAM_CMD, keep an internal variable to keep track of the offset and start commands by setting REG_CMD_WRITE.
I gave that up years ago with v5 of my library only writes to REG_CMDB_WRITE but lost FT80x compatibility in return.
And checking back with the Riverdi and Bridgetek implementations, the River version does not do it but the Bridgtek version can do both APIs now.
The main difference between using RAM_CMD+offset and REG_CMDB_WRITE is that with the first you need to set REG_CMD_WRITE manually in order to execute commands and with writing to REG_CMDB_WRITE commands are started automatically as REG_CMD_WRITE is advanced automatically.

My EVE_execute_cmd() is only what is left of the original function, it does not need to start command execution anymore, only wait for completion.
And my EVE_busy() function does by istself not wait, it only provides information about the current state of the FIFO and as it reads REG_CMDB_SPACE this was the perfect place to do co-processor fault recovery as well.

When building display lists I never wait for command execution in between, only when using commands like CMD_INFLATE that are not meant to be used in display lists.
With my EVE_start_cmd_burst() / EVE_end_cmd_burst() functions I even write all commands in between in one SPI operation, eliminating the 3 byte address overhead that is necessary for individual commands.
One of the reasons why my implementation is the fastest.

What I currently do not have is support for TIs TM4C controllers though.

I just added targets for the two boards that are supported by PlatformIO to my Arduino example.
But the Arduino core in there does not seem to have a SPI class.
If it had SPI support it should have compiled with my generic Arduino "driver".

And for non-Arduino use I should order an EK-TM4C1294XL.
I can't see me using a TM4C controller for anything else than adding support to my library, these are over ten years old now and just do not have what I would need to switch from the ATSAME51 I currently prefer to use.

[cvu1]

I'm using TM4C1294 so it close to MSP432. They both Core Arm M4F. I'm working on Embedded System so coding style will be close to Arduino/MSP430. I guess I will start working on my own API using REG_CMDB_WRITE to optimize the data transfer. The product I'm working on is using latest display EVE4 so the API from Riverdi and Bridgetek may not optimize for the EVE4 anymore as you said.

[RudolphRiedel]

As I wrote, Bridgeteks library can use REG_CMDB_WRITE now as well.

And I don't know much about MSP430 / MSP432 either.
Back when MSP430 was released there was no free compiler for it and professionally I never had the opportunity to use a TI controller.

[cvu1]

Yeah, I do see Bridgetek use REG_CMDB_WRITE but their code look kind of messy for me and at some point hard to follow. I may based on their code, clean up to give a clean, easy follow APIs to use on my project and only use REG_CMDB_WRITE to help improve the display time. The APIs from Riverdi, because it write to RAM_CMD, it do keep track of cmd_fifo in HalContext structure and waste time because it need to read back from EVE to track the cmd fifo size. It seems like your library doesn't use any structure to keep track of things. Because my device is in medical field, it really tricky on third library use in the project that requires from FDA. Either I have to use the API provided from the Bridgetek (EVE4 IC provider) or Riverdi (Display Module provider), other wise, I have to come up with my own APIs.

Thanks for your information. This is first time I think about using REG_CMDB_WRITE. Let see how things going.

[cvu1]

@RudolphRiedel In your _burst function. How you keep track the bytes you sent to cmd_fifo? I look at your TFT_display(). Your start with EVE_start_cmd_burst() - CS_low and end with EVE_end_cmd_burst() --> cs_high --> cmd-FIFO will executed automatically. I don't see you keep track how many bytes you already sent to the the RAM_CMD. You have the EVE_busy() to read back the space but I only see you run it in your Touch function. How you know if you send more than 4k bytes in TFT_display() ?

[RudolphRiedel]

My library does not keep track of the bytes sent to the cmd FIFO as this is a static value for any given display list.
Instead I am using debug-output at the bottom of the screen during development:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/example_pics/EVE3_43G_ATSAME51.jpg
Bytes: 224 - this is how many bytes were sent with the previous display list
Time1: 14µs - this is how long the function TFT_display() ran for the previous display list (target uses DMA for SPI transfers)

So while it may look like I am sacrificing safety for speed, I am really not, since display lists are not just getting shorter or longer dynamically.

As for compliance, the fundamental API is exactly the same, only the names differ.
EVE_cmd_text() does exactly what is described in the programming guide.
I do have an EVE_cmd_text_var() function though to handle the BT81x OPT_FORMAT, but for the most part this is to avoid using a variadic function and needing to count arguments at runtime that are fixed at compile time anyways.

Also I am testing my library against MISRA-C 2012 and BARR-C 2018 compliance.
And for the most part it is compliant.

What you would need is a target file for the TM4C like one of these:
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/src/EVE_target/EVE_target_MSP432.h
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/src/EVE_target/EVE_target_GD32C103.h

And an enty in EVE_target.h for it.

[cvu1]

@RudolphRiedel

I'm working on using REG_CMDB_WRITE now. So far everything working fine. Just one question when using CMD_FLASHREAD. This command is for copy Bitmap/xFont to RAM_G. When using with REG_CMDB_WRITE, it won't trigger right away and time to copy from Flash to RAM_G is take time. How you deal with this? Do I need to set CS high right after CMD_FLASHREAD and wait for certain time to make sure everything is in RAM_G before I continues using REG_CMDB_WRITE?

[RudolphRiedel]

Technically the FIFO can be filled with more commands while CMD_FLASHREAD is beeing worked on by the co-processor.
And this probably applies to a couple of other commands as long as these are not depending on each other.
But I like things a bit cleaner and more predictable.
As long as the FIFO is not full it is fine to issue more commands.

[cvu1]

Let say I need to load a bitmap that half size of my screen (1024x600) from Flash to RAM_G.

Ex:

`Gpu_Cmd_Burst_SendCmd(phost, CMD_DLSTART); // Start with CS LOW and REG_CMDB_WRITE

Gpu_Cmd_Burst_SendCmd(phost, CLEAR_COLOR_RGB(255, 255, 255));
Gpu_Cmd_Burst_SendCmd(phost, CLEAR(1,1,1));

Gpu_Cmd_Burst_FlashRead(phost, RAM_G, 0, 780160);

Gpu_Cmd_Burst_SetBitmap(phost, RAM_G, RGB565, 721, 541);

Gpu_Cmd_Burst_SendCmd(phost, COLOR_RGB(0xFF,0xFF,0xFF));
Gpu_Cmd_Burst_SendCmd(phost, BEGIN(BITMAPS));
Gpu_Cmd_Burst_SendCmd(phost, VERTEX2F(19116, 16616));
Gpu_Cmd_Burst_SendCmd(phost, END());
Gpu_Cmd_Burst_SendCmd(phost, DISPLAY());
Gpu_Cmd_Burst_SendCmd(phost, CMD_SWAP);

Gpu_Cmd_Burst_End(phost); // CS High`

So when I get CS High, will the flash already write to RAM_G and ready for CMD_SWAP? will the CMD_SWAP wait for RAM_G to be filled before it display anything on screen? Because during display at some point, I have to update RAM_G for other bitmap/xfont.

In another word. When sending CMD_FLASHREAD to cmd fifo, does the EVE copy data from Flash to RAM_G right away or it have to wait for CS go high?

[RudolphRiedel]

I am not entirely sure if the command execution starts right away or if it requires CS to go high first.
My guess would be it starts with CS going high.
However, the commands are processed sequentially, so either way the CMD_FLASHREAD is executed first and finished and then CMD_SETBITMAP is executed.
But I would not mix commands that create display list entries and commands that are not display list related like this.
More specifically for something likes this I would use ASTC 8x8 as image format and have two images to swap between.
If you want to swap the image thas is displayed like this the previous display list still is executed untill some time after CMD_SWAP, so there might be some distortion while the data is copied.

[cvu1]

I have Display_Test() call in while loop every 1 second. Each time, it will display new image that copy from flash to RAM_G. How you handle this?

1. My first attemp.

2. void Display_Test(void){

    uint8_t ANIMATION = 0;
    
    // Copy Images to ram_g
    switch(ANIMATION) {
    case 0:
    	Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_1_ADDRESS, ANIMATION_SIZE);
    	ANIMATION = 1;
    	break;
    case 1:
    	Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_2_ADDRESS, ANIMATION_SIZE);
    	ANIMATION = 2;
    	break;
    case 2:
    	Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_3_ADDRESS, ANIMATION_SIZE);
    	ANIMATION = 0;
    	break;
    }
   
    // start Burst display
    Gpu_Cmd_Burst_Space(phost);	// make sure space is 4092 
    Gpu_Cmd_Burst_SendCmd(phost, CMD_DLSTART);
    Gpu_Cmd_Burst_SendCmd(phost, CLEAR_COLOR_RGB(255, 255, 255));
    Gpu_Cmd_Burst_SendCmd(phost, CLEAR(1,1,1));
    
    // Draw Bitmap
    Gpu_Cmd_Burst_SetBitmap(phost, RAM_G, RGB565, ANIMATION_W, ANIMATION_H);
    Gpu_Cmd_Burst_SendCmd(phost, COLOR_RGB(0xFF,0xFF,0xFF));
    Gpu_Cmd_Burst_SendCmd(phost, BEGIN(BITMAPS));
    Gpu_Cmd_Burst_SendCmd(phost, VERTEX2F(191*16, 166*16));
    Gpu_Cmd_Burst_SendCmd(phost, END());
    
    Gpu_Cmd_Burst_SendCmd(phost, DISPLAY());
    Gpu_Cmd_Burst_SendCmd(phost, CMD_SWAP);
    Gpu_Cmd_Burst_End(phost);
   

   }

Doesn't work, some how it tried to draw 3 bits map at one. Space is always at 0 (space = Gpu_Hal_Rd16(phost, REG_CMDB_SPACE) & FIFO_SIZE_MASK;). Not sure why. I guess SetBitMap can't use with other cmd in one transmistion.

I'm not sure how to handle this. Any suggestion?

[RudolphRiedel]

Other than the ANIMATION variable missing "static" inside that function I am not seeing why this could fail under the given premise of calling it once per second.

But like I wrote, this way the image gets displayed while it is been overwritten with the next one.

[cvu1]

I'm just testing display image only. But it doesn't works as the way I want. The old way seem more stable but I do like the speed of burst. Let me play around to see if there any way to fix this.

[cvu1]

@RudolphRiedel This is my test run. have you tried to display bitmaps with burst before? I'm not sure why burst with bitmap doesn't works for me.

#define ANIMATION_1_ADDRESS 348480
#define ANIMATION_2_ADDRESS 645312
#define ANIMATION_3_ADDRESS 942144

#define ANIMATION_SIZE 296800
#define ANIMATION_W 371
#define ANIMATION_H 400

// Display call every 1 second
void Display()
{

static uint8_t Animation = 0;

#ifdef BURST
// Using Burst REG_CMDB_SPACE. Display function take 188 us to finished
// But the Images keep fickering by switching between 3 bitmaps in one run.
//

switch(Animation) {
case 0:
    Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_1_ADDRESS, ANIMATION_SIZE);
    Animation = 1;
    break;
case 1:
    Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_2_ADDRESS, ANIMATION_SIZE);
    Animation = 2;
    break;
case 2:
    Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_3_ADDRESS, ANIMATION_SIZE);
    Animation = 0;
    break;
}

TimingIO(0); // start timing = 0

Gpu_Cmd_Burst_SendCmd(phost, CMD_DLSTART); // CS LOW with REG_CMDB_WRITE
Gpu_Cmd_Burst_SendCmd(phost, CLEAR_COLOR_RGB(255, 255, 255));
Gpu_Cmd_Burst_SendCmd(phost, CLEAR(1,1,1));

Gpu_Cmd_Burst_SetBitmap(phost, RAM_G, RGB565, ANIMATION_W, ANIMATION_H);
Gpu_Cmd_Burst_SendCmd(phost, COLOR_RGB(0xFF,0xFF,0xFF));
Gpu_Cmd_Burst_SendCmd(phost, BEGIN(BITMAPS));
Gpu_Cmd_Burst_SendCmd(phost, VERTEX2F(191*16, 166*16));
Gpu_Cmd_Burst_SendCmd(phost, END());

Gpu_Cmd_Burst_SendCmd(phost, DISPLAY());
Gpu_Cmd_Burst_SendCmd(phost, CMD_SWAP);
Gpu_Cmd_Burst_End(phost);   			// CS HIGH - Display cmd to co-pro

TimingIO(1); // end timing = 115.52 us

#else
// Using circular buffer RAM_CMD. Display function take 13.49ms to finished

Gpu_CoCmd_Dlstart(phost);
App_WrCoCmd_Buffer(phost, CLEAR_COLOR_RGB(255, 255, 255));
App_WrCoCmd_Buffer(phost,CLEAR(1,1,1));

switch(Animation) {
case 0:
    Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_1_ADDRESS, ANIMATION_SIZE);
    Animation = 1;
    break;
case 1:
    Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_2_ADDRESS, ANIMATION_SIZE);
    Animation = 2;
    break;
case 2:
    Gpu_CoCmd_FlashRead(phost, RAM_G, ANIMATION_3_ADDRESS, ANIMATION_SIZE);
    Animation = 0;
    break;
}

TimingIO(0); // start timing = 0

Gpu_CoCmd_SetBitmap(phost, RAM_G, RGB565, ANIMATION_W, ANIMATION_H);
App_WrCoCmd_Buffer(phost, COLOR_RGB(0xFF,0xFF,0xFF));
App_WrCoCmd_Buffer(phost, BEGIN(BITMAPS));
App_WrCoCmd_Buffer(phost, VERTEX2F(320*16, 125*16));
App_WrCoCmd_Buffer(phost, END());

App_WrCoCmd_Buffer(phost, DISPLAY());
Gpu_CoCmd_Swap(phost);
App_Flush_Co_Buffer(phost);
Gpu_Hal_WaitCmdfifo_empty(phost);

TimingIO(1); // end timing = 13.28ms

#endif
}

[RudolphRiedel]

I have not tried something like this in particular with CMD_FLASHREAD before building the display list.
But I almost always use what I called "burst" mode for building display lists and usually in combination with DMA, so even more tightly packed on the SPI.

Now I kind of wonder though what this looks like.
And with that tought, do you have a logic analyzer and get a trace of what you are sending there?

[cvu1]

I do have Logic Analyzer, the burst mode sending correct data. Even the CMD_FLASHREAD. Because in burst mode, I don't use CMD_FLASHREAD in burst mode so I this should work as it works in other mode.
In Burst mode. When CMD_FLASHREAD is trigger, this should tell the co-pro to copy bitmap to RAM_G. Other command is just for DL, doesn't deal with flash. When it start drawing, what I guess is bitmap haven't finished copy to RAM_G, this lead to the bitmap flickering, display at random position and random bitmap. What I see on the display is it try to display all 3 bitmaps in one run. But this weird to me because I only call CMD_FLASHREAD one and SetBitmap/BEGIN(BITMAPS) one. But the screen display all 3 images really fast for first fews seconds and then the bitmaps no longer refresh even the Display function still running. But the new bitmap never update.

[cvu1]

I use CMD_FLASHREAD because the TM4C only have 1MB internal flash. Storing bitmaps, custom fonts. So CMD_FLASHREAD is what I frequently used when it need. What I'm doing now is just for testing Burst with Flash but it doesn't work out for me at the moment. I'm still working on this to see why.

[cvu1]

I know why. After SWAP, we need to wait to make sure Cmdfifo empty. Gpu_Hal_WaitCmdfifo_empty(); or (REG_CMDB_SPACE == 4092). But if waiting for Cmdfifo be empty, then the Display time in both case with/without burst mode will be 13.49ms as I measured. So best fix will be before starting burst mode, make sure Cmdfifo is empty. What I need to test is determine how long does EVE4 take to make cmdfifo empty from full.

[RudolphRiedel]

I know why. After SWAP, we need to wait to make sure Cmdfifo empty.

No, not really, given the premise of calling the function once per second the FIFO will always be empty, unless there was a co-processor error.

I tried this now and even added a special version of EVE_cmd_flashread() that only works in my burst mode:

void EVE_cmd_flashread_test(uint32_t dest, uint32_t src, uint32_t num)
{
    spi_transmit_burst(CMD_FLASHREAD);
    spi_transmit_burst(dest);
    spi_transmit_burst(src);
    spi_transmit_burst(num);
}

I took a bunch of icons in .png with alpha channel and 256x256 pixels and converted these:
bt817.blob : 0 : 4096
4021462_lock_protect_security_shield_virus_icon_256x256_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 4096 : 16384
4638319_countries_location_map_pin_world_icon_256x256_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 20480 : 16384
5929138_clean_cleaning_hands_wash_washing_icon_256x256_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 36864 : 16384
5929139_clean_cleaning_hands_wash_washing_icon_256x256_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 53248 : 16384
5994825_clean_hands_hygienic_sanitary_wash_icon_256x256_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 69632 : 16384
6075419_cleanliness_color_covid_lineal_protect_icon_256x256_COMPRESSED_RGBA_ASTC_8x8_KHR.raw : 86016 : 16384
4021462_lock_protect_security_shield_virus_icon_256x256_ARGB1555.raw : 102400 : 131072
4638319_countries_location_map_pin_world_icon_256x256_ARGB1555.raw : 233472 : 131072
5929138_clean_cleaning_hands_wash_washing_icon_256x256_ARGB1555.raw : 364544 : 131072
5929139_clean_cleaning_hands_wash_washing_icon_256x256_ARGB1555.raw : 495616 : 131072
5994825_clean_hands_hygienic_sanitary_wash_icon_256x256_ARGB1555.raw : 626688 : 131072
6075419_cleanliness_color_covid_lineal_protect_icon_256x256_ARGB1555.raw : 757760 : 131072

After writing the image to the external flash I added one pair of flash_read to my TFT_init():

    if (E_OK == EVE_init_flash())
    {
        EVE_cmd_flashread(0, 4096, 16384);
        EVE_cmd_flashread(0x5000, 102400, 131072);
    }

And then I added displaying these images to my TFT_display() that is called every 25ms:

        EVE_color_rgb(WHITE);
        EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);

        EVE_cmd_setbitmap(0, EVE_ASTC_8X8, 256U, 256U);
        EVE_cmd_dl(VERTEX2F(0, 80));

        EVE_cmd_setbitmap(0x5000, EVE_ARGB1555, 256U, 256U);
        EVE_cmd_dl(VERTEX2F(300, 80));

        EVE_cmd_dl(DL_END);

And the two icons got displayed.
And despite 1/8 the size the ASTC 8x8 looks better, it looks like it had some anti-aliasing applied.
I did switch off the "dither" option for the ARG1555 icons though that is set by default in EAB.

Now I added code to my TFT_display() to read new images from flash once per second like you did.

    static uint8_t display_delay = 0;
    static uint8_t icon_number = 0;
...
        display_delay++;
        if(display_delay > 24)
        {
            display_delay=0;
            
            switch(icon_number)
            {
                case 0:
                        EVE_cmd_flashread(0, 4096, 16384);
                        EVE_cmd_flashread(0x5000, 102400, 131072);
//                        EVE_cmd_flashread_test(0, 4096, 16384);
//                        EVE_cmd_flashread_test(0x5000, 102400, 131072);

                        break;
...
            }

            icon_number++;
            if(icon_number > 5)
            {
                icon_number = 0;
            }
        }

And like this with my normal EVE_cmd_flashread(), one call when the images are read from flash needs about 5.9ms.
I can even drop the "if(display_delay > 24)" to "if(display_delay > 0)" and it works, switching the icons 25 times per second.

When I switch over to use EVE_cmd_flashread_test() the execution time drops to 18µs with DMA and 172µs without DMA.
The reduction of the time spent is nice for the host controller, perhaps I should add variations of a couple of functions like EVE_cmd_flashread() that do not wait for completion.
But then in this example EVE still needs about 6ms to execute what is in RAM_CMD, so I still would prefer to copy all the images to RAM_G before displaying anything.

The bytes sent to the FIFO are 252 normally and 284 with the two EVE_cmd_flashread_test().

[cvu1]

@RudolphRiedel Thank for your information. I just find out that the my Logic Analyzer causing noise to the SPI signal that give my display running crazy. It doing better now. The problem I have is because the RAM_G only 1MB and the bitmap for each screen is big so I can't copy all the images to RAM_G at Init state. Also, xfont and font cache also take some space in RAM_G too so the worst case that I have to re arrange data in RAM_G for new screen. Also, my MCU doing application along with display. I have to make sure that display function must finished within 50ms (worst case 100ms) so the MCU still have time to do other tasks.

[RudolphRiedel]

Well, convert to ASTC 8x8 and you can put 8 times more images in RAM_G. :-)
And 50ms is a long time, my target was to stay below 1ms - when I was not using DMA on an 8-bit AVR.

[cvu1]

I will try with ASTC. I tried ASTC before and the image quality is not really good compare to RGB565. And I do see each version of EVE Asset Builder give me different results, including convert images, custom fonts. I find that EVE Asset Builder 2.6.1 is best stable for me. Same custom fonts/characters list, same setup, v2.6.1 and v2.10.2 give me different result. I may start testing display images directly on Flash using ASTC and see how long does it takes.

[RudolphRiedel]

Here are the icons I used side by side, left is ASTC 8x8, right is ARGB_1555:

Converted with EAB 2.10.2