load data to external flash of riverdi board through stm32

[Adam]

Hello
I'm working on a embedded system using a stm32 and Riverdi 7" 1024x600 EVE4 BT817 display with 512Mb flash chip. I'm also using the excellent EVE library from Rudolph.
I followed the instructions given here to connect external flash and write and read to it.
http://www.brtcommunity.com/index.php?topic=320.msg1458#msg1458
I can change status of external flash and read size of it and also i can read and write to RAM_G by EVE_memWrite_sram_buffer() But EVE_cmd_flashupdate and CMD_FLASHREAD (read and write from external flash)not work.
Hopefully someone (like Rudolph) and point me to solve problem.
Thanks.
   

[BRT Community]

Hello,

Thank you for your post.

Would you be able to share the code you are using when calling FLASHUPDATE and FLASHREAD?
Please note: the CMD_FLASHUPDATE command will erase a sector (4096 bytes) in the flash memory before writing the new data into the flash IC, as such all FLASHUPDATE calls must be 4K byte alligned.

Best Regards,
BRT Community

[Rudolph]

(wall of text deleted again)

What are you actually trying to do?

Note that for EVE_cmd_flashupdate(uint32_t dest, uint32_t src, uint32_t num) the destination needs
to be 4096 byte aligned, the source needs to be 4 byte aligned and the number of bytes needs to be a
multiple of 4096.

[Adam]

Hello
Thank you for your reply.

I found the problem.It's my mistake. I missed EVE_LIB_BeginCoProList command before EVE_CMD_FLASHUPDATE and EVE_CMD_FLASHREAD. Of course in Programming Guide Document in not mentioned about this point and in i found it in uploaded example.

Loading directly ASTC format image from flash to display is done correct but now i have another problem with using EVE_VERTEX2II function. When i use this function to giving coordinate for a bitmap, the x coordinate work properly but nonzero y coordinate cause corrupted display!

Like this:
http://www.brtcommunity.com/index.php?topic=285.msg1341#msg1341

Is solved?

EVE_VERTEX2II work completely good with same image that load from RAM_G.

[Rudolph]

I missed EVE_LIB_BeginCoProList command before EVE_CMD_FLASHUPDATE and EVE_CMD_FLASHREAD.

So you are not using my library then, this is AN025.

Of course in Programming Guide Document in not mentioned about this point and in i found it in uploaded example.

The reason is that none of the commands in AN025 care about chip-select or write the address, even commands like these which are not meant to go in a display list.
And you need a call to EVE_LIB_EndCoProList() as well.
Plus you need to add a line to wait for the command to be executed.

I sorted the functions in my library by commands that are used in display lists and commands that are used outside display lists. And those to be used outside display lists are self-contained, meaning these set chip-select, write the address and wait for the command to be executed if necessary - and the comment says so.

[Adam]

Can anyone HELP?

[BRT Community]

Hello,

Can you just confirm if you are seeing issues where the Y coordinate is a negative number or if it is any non zero integer?

Best Regards,
BRT Community

[Adam]

Hello again

Thanks for your reply.

Can you just confirm if you are seeing issues where the Y coordinate is a negative number or if it is any non zero integer?

Y coordinate that i used is positive and i test with another image with different size(72x72) and y coordinate work correct but still previous image(256x152) corrupted with y coordinate. Is it strange Or size affects on function or ...?

[Adam]

Hello BRT Community
I can NOT understand relation between Y coordinate and image size ... !
Another thing about max image size that loaded directly from flash. Apparently there is limitation. For example 1024x600 image can not load and screen turns white but 512x600 image load correctly.
Do you confirm that?

[BRT Community]

Hello,

There shouldn't be any issues when using a positive value for the Y coordinate when placing an image from flash.

Could you provide the images you are seeing these issues with?

As for the larger image not loading, it sounds like you are hitting the throughput limitation of the flash SPI interface for the IC, there is a limit on the amount of data which can be red during one screen refresh from flash. You could try lowering the screen refresh rate or utilising Adaptive Frame Rate to see if this helps with the larger images.

Best Regards,
BRT Community

[Adam]

As for the larger image not loading, it sounds like you are hitting the throughput limitation of the flash SPI interface for the IC, there is a limit on the amount of data which can be red during one screen refresh from flash. You could try lowering the screen refresh rate or utilising Adaptive Frame Rate to see if this helps with the larger images.

This problem fixed.It's about EVE_config library. I don't know why EVE_DISP_PCLK_FREQ is set 0xd12 !!!(In other library is 51MHz)
I changed it to 51000000 , EVE_DISP_PCLK to 20 , EVE_DISP_HCYCLE to 2000 so loading image directly from flash work properly.
I still don't understand why. Is there an explanation for this?

[BRT Community]

Hello,

Thanks for the update, I'm glad you have managed to display the image now.

As per table 4-11 in the datasheet 0xd12 should equate to 51Mhz on for the PCLK frequency:
https://brtchip.com/wp-content/uploads/Support/Documentation/Datasheets/ICs/EVE/DS_BT817_8.pdf

I would also recommend setting REG_HCYCLE to the value noted in your displays datasheet, as the display is has a width of 600 the HCYCLE value should be close to this number as this denotes the number of Horizontal scan out lines EVE has to process.

The EVE series of ICs do not include a frame buffer, they dynamically clock out each computed pixel on the screen for every screen refresh. A displays size and what the Pixel Clock is running at will determine the achievable performance, and conversely how long EVE has to pull any graphic asset data from an attached flash IC.

If we take the following example from the following WQVGA settings for working out a displays frame rate i can explain what has happened (note: this is an FT81x example but the princile still applies):
 

Code Select Expand

  // WQVGA display parameters
   lcdWidth   = 800;                                                            // Active width of LCD display
   lcdHeight  = 480;                                                            // Active height of LCD display
   lcdHcycle  = 928;                                                            // Total number of clocks per line
   lcdHoffset = 88;                                                             // Start of active line
   lcdHsync0  = 0;                                                               // Start of horizontal sync pulse
   lcdHsync1  = 48;                                                            // End of horizontal sync pulse
   lcdVcycle  = 525;                                                           // Total number of lines per screen
   lcdVoffset = 32;                                                            // Start of active screen
   lcdVsync0  = 0;                                                              // Start of vertical sync pulse
   lcdVsync1  = 3;                                                              // End of vertical sync pulse
   lcdPclk    = 2;                                                                  // Pixel Clock
   lcdSwizzle = 0;                                                              // Define RGB output pins
   lcdPclkpol = 1;                                                              // Define active edge of PCLK
                   

HCYCLE = 928
VCYCLE = 525
VCYCLE * HCYCLE  = 487,200

Note: REG_PCLK is using the value 2 which will divide PCLK down to 30Mhz.

Result = 30,000,000/487,200 = ~ 61 fps


From the above example we can see that the pixel clock and the display settings affect the refresh rate, again the slower a screen refresh rate the longer EVE has to process any data to draw the screen or pull data from an attached flash IC.

In your case it would appear that you maintained the EVE_DISP_PCLK_FREQ (PLCK frequency) setting and are clocking the display at 2.55Mhz where REG_PLCK = 20 (Note: you may want to check your displays datasheet to check the applicable range for its pixel clock). You have also set REG_HCYCLE to 2000, this along with slowing the pixel clock has the effect that it will slow down the displays refresh rate, thus allowing more time for EVE and the SPI interface to pull the image data from flash and construct the screen for the given screen refresh.

Again, i would suggest resetting REG_HCYCLE to your display recommended value, you can then play with the pixel clock (via EVE_DISP_PCLK_FREQ and EVE_DISP_PCLK) until you are not experiencing underrun whilst loading the image from flash.

Best Regards,
BRT Community