Print

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

[vdc]

Hi all,

Is there any way that I can read the CheckSum from the Flash on EVE3 module?

Right now, I'm storing all the image, custom font on the FLash on EVE3 module. But I need to find a way to verify that the data on the flash is correct version with my MCU program. Otherwise, it will display wrong information that I want.

Best regards,

[Rudolph]

As I never have used it I was curious if CMD_MEMCRC could be used for this.
But unfortunately it does not work for the flash.

I tried this with an EVE3-50G which uses a BT815:

crc_flash = EVE_cmd_memcrc(0x800000,2048);

And it hangs, the display just stays dark.

This works fine though:
EVE_cmd_flashread(0, 0, 2048);
crc_sram = EVE_cmd_memcrc(0,2048);

I also tried several other variants which all worked:
 crc_flash = EVE_cmd_memcrc(0x1E0000,2048);
 crc_flash = EVE_cmd_memcrc(0x309800,2048);
 crc_flash = EVE_cmd_memcrc(0x400000,2048);
 crc_flash = EVE_cmd_memcrc(0x100000,2048);
 crc_flash = EVE_cmd_memcrc(0x001000,2048);
 crc_flash = EVE_cmd_memcrc(0x600000,2048);
 crc_flash = EVE_cmd_memcrc(0x700000,2048);
 crc_flash = EVE_cmd_memcrc(0x780000,2048);

Yes, okay, the returned value is meaningless but at least it does not hang.

So EVE can calculate a CRC32 but the data needs to be copied to RAM_G first.

And what I could not find in the programming guide, it says EVE "computes a CRC-32" but not how.
I played with an online tool that calculates a whole bunch of CRC values and it looks like EVE
is using poly = 0x04C11DB7 and init = 0xFFFFFFFF.

[vdc]

Hi  Rudolph,

Thank you for the reply.

based on your code, I have able to read the data from the Flash. Just somehow the first byte I read is 0xFF

My bin file that I create from the Asset Builder that contain the .blob and .raw file.
unified.blob                             : 0    : 4096
B_colorpulse_j84cnclv_800x480_RGB565.raw : 4096 : 768000

I use the Hex Editor to read the HEX value from the bin file.
0x00: 70 df fb 92 1e 01 00 00 e8 a6 30 00 18 01 10 00
0x1F: 00 00 f8 da 4a a7 2a ff ff ff ff ff ff ff ff ff

Code from my MCU

===============================
    Gpu_CoCmd_FlashRead(phost, 0, 0, 4*4);  // read first 16 bytes from the Flash

    for(i = 0; i < 20; i++) {
        // read 1 byte from RAM_G
        read = Gpu_Hal_Rd8(phost, RAM_G + i);
        UARTprintf("%d: 0x%02x\r\n", i, read);
    }
===============================

And I got

0: 0xff
1: 0xdf
2: 0xfb
3: 0x92
4: 0x1e
5: 0x01
6: 0x00
7: 0x00
8: 0xe8
9: 0xa6
10: 0x30
11: 0x00
12: 0x18
13: 0x01
14: 0x10
15: 0x00
16: 0xff
17: 0xff
18: 0xff
19: 0xff


It is correct from the 2nd byte. But I don't know why the first byte is 0xFF, it should be 0x70. Not sure where I did wrong.

Also, for the MEMCRC command. It say that it can computes a block of memory. I use the winbond flash. And 1 block = 64Kb.

EVE_cmd_memcrc(0x1E0000,65535);  ---> will it do the job?

Thank you so much.

[Rudolph]

based on your code, I have able to read the data from the Flash. Just somehow the first byte I read is 0xFF

0x00: 70 df fb 92 1e 01 00 00 e8 a6 30 00 18 01 10 00
0x1F: 00 00 f8 da 4a a7 2a ff ff ff ff ff ff ff ff ff

That is strange.
My Hex-Editor shows the exact same sequence and I just printed out the first 16 bytes on
the display and these do match as well.

I am using my own code library: https://github.com/RudolphRiedel/FT800-FT813
This really should not make any difference though since this is basic functionality.

Also, for the MEMCRC command. It say that it can computes a block of memory. I use the winbond flash. And 1 block = 64Kb.

EVE_cmd_memcrc(0x1E0000,65535);  ---> will it do the job?

It won't do much good as the address is ROM_FONT. :-)

I just tried it and apparently there is no limit on the size CMD_MEMCRC can process.
Well, it can't go past 0x7fffff but this not much of a limitation. :-)

This really is working:
crc_sram = EVE_cmd_memcrc(0,0x7fffff);

This is not working:
crc_sram = EVE_cmd_memcrc(0,0x800000);

Although technically the last address it should read from would be 0x7fffff.


So this is no problem at all:
crc_sram = EVE_cmd_memcrc(0,0xffff);

And I roughly timed it.
EVE_cmd_memcrc(0,0xfffff); ~3.5ms
EVE_cmd_memcrc(0,0xffff); ~280µs

It is possible though that the execution time depends on the memory content but I was not able to tell a difference
with the way I measured it and with the jitter on the measurements when adding this line.

[vdc]

Hi Rudolph,

I just find out that I don't have the EVE_busy function that why the first byte I read I incorrect.

However, I have one question. I look at your EVE_busy function, I see that you use REG_CMDB_SPACE for check the busy.

Why you use that?

I'm using the Gpu libary from BRT which they have a function call Gpu_Hal_WaitCmdfifo_empty

==================
void Gpu_Hal_WaitCmdfifo_empty(Gpu_Hal_Context_t *host)
{
    while(Gpu_Hal_Rd16(host,REG_CMD_READ) != Gpu_Hal_Rd16(host,REG_CMD_WRITE));

    host->cmd_fifo_wp = Gpu_Hal_Rd16(host,REG_CMD_WRITE); // update fifo to 0
}
===================

This also will check if the EVE is busy.

I just wonder why you use difference way to check the EVE busy by REG_CMDB_SPACE  and REG_COPRO_PATCH_DTR?

Best regards,

[Rudolph]

I switched from using REG_CMD_READ / REG_CMD_WRITE to use REG_CMDB_WRITE / REG_CMDB_SPACE.
My EVE_busy() function in release 4 did not read REG_CMD_WRITE though, I was keeping track of that value in a variable
with every command and only writing it:

Code: [Select]

uint8_t EVE_busy(void)
{
 uint16_t cmdBufferRead;

 cmdBufferRead = EVE_memRead16(REG_CMD_READ); /* read the graphics processor read pointer */
 ....
 if(cmdOffset != cmdBufferRead)
 {
   return 1;
 }
 else
 {
   return 0;
 }
}

So when I switched from writing REG_CMD_WRITE to REG_CMDB_WRITE I also dropped keeping track of the
current position in the command-FIFO.

The easy fix would have been reading REG_CMD_READ and REG_CMD_WRITE.
But this is significantly slower since memRead16() needs to send 6 bytes over the SPI.

And then there is this: http://www.brtcommunity.com/index.php?topic=175.msg825#msg825
As my EVE_busy() function also is trying to catch co-processor faults my first version for release 5
was reading both REG_CMD_READ and REG_CMDB_SPACE.
That REG_CMDB_SPACE is showing co-processor faults is missing from the programming guide.

[vdc]

Hi Rudolph,

You know what is the best way to get the CRC-32 for the entire Flash?

Currently, I can only read 1 MB (1048576 bytes) from Attach Flash to the RAM_G and do the MEMCRC from the RAM_G. And then I use the MEMCRC to get the CRC-32 from the RAM_G, but this only give me the CRC-32 from 1 MB of the Flash. I'm having 16MB now, so I will need to read it 16 time and get 16 difference CRC-32 values.

I use the HxD to calculate the whole .bin file and get one CRC-32 value for the .bin file that will be download to the attach flash.

Is there any other way to add all the CRC-32 that I got from MEMCRC so that final value will equal to the CRC-32 from .bin file?

I have been searching on google but no success.

I'm thinking about reading every bytes from RAM_G and manual do the CRC-32 but I think this will take too long since I can only read 32-bits at one with rd32 command from MCU.


Here is my code from Tiva C
=====================
    Gpu_CoCmd_FlashRead(phost, RAM_G, 0, 1048576);  // Read 1MB from Flash to RAM_G
    while(EVE_busy());  // Wait until transfer is complete

    cmdoffset = Gpu_Hal_Rd16(phost, REG_CMD_WRITE);
    Gpu_CoCmd_MemCrc(phost, RAM_G, 1048576, 0);
    while(EVE_busy()); //wait till the command is complete

    read = Gpu_Hal_Rd32(phost, RAM_CMD + cmdoffset + 12); //RAM_CMD
    UARTprintf("CRC: 0x%08x\r\n", read);
======================



Best regards,

[Rudolph]

Well, I was kind of hoping that Bridgetek would shed some light on the available options regarding the FLASH.
The fastest way to do this without further information probably is to let EVE calculate 16 CRC32 values, one for each block.

There are a couple of undocumented registers and there is a REG_CRC amoung these.
I just played with it in hope CMD_MEMCRC would use the content of that register as a starting value for the CRC32
and therefore allow calculating the CRC32 over a series of blocks.
But unfortunately writing to this register does not seem to have any effect on the CRC.
And when reading from it the result is the XOR value of the last CRC32.

Now I went deeper into the woods and wrote a program that displays blocks of eight 32-bit values with their addresses and increase that every time a buttom is pressed.
I wrote down all the addresses from which 0xffffffff was read.
And then I added two CMD_MEMCRC with writing the result of the first CMD_MEMCRC to one of the registers
I found with 0xffffffff.
Unfortunately this had no effect on the result of the second CMD_MEMCRC.

I even peeked in the region 0x309900 and beyond but this is kind of a mine-field to poke around as there is code.
0x30a800 to 0x30afff returns 0xdeadbeef :-)
The code for the touch-controller begins at 0x30b000 and is followed by whatever up to 0x30b7ff.
0x30b800 and beyond does not seem to return anything else anymore than 0xdeadbeef.

@Bridgetek
Is it even possible to "patch" CMD_MEMCRC this way so that it uses the result of the previous calculation
as starting value for the next block?
If so, to which address that normally contains 0xffffffff can we write?
And if different, for both the BT815 and the BT817, please.