FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Author Topic: FT813 CRC calculating and adressing  (Read 12748 times)

gokhannsahin

  • Newbie
  • *
  • Posts: 21
    • View Profile
FT813 CRC calculating and adressing
« on: July 27, 2018, 08:04:47 PM »

Hi everyone,
I'm using the FT813 in my project and it has lots of images is around 66 on a screen but almost all is small picture or symbol.
I'm using the crc calculating avoid errors while transferring. However, I'm confused a point in the datasheet, it says that read to ıf CommandWriteAddress + 12 to get the calculated crc value. Well, if this command address is 4092, I still have to read +12, so 4092+12? If yes, then, will there be an overflow in command buffer? Or should the (4092+12)-4096=8th address be read?

Furthermore, I'm using a shadow command buffer and inserting the commands to it. Then they are sent to FT813 via DMA as the following example. Each transfer before, I read the reg_cmd_write and add the new commands to it. However, it read 2048 from reg_cmd_write and need 3012 bytes commands. What can I do at this point? Should I add 3012 to 2048 that is equal to 5060? Or clear the cmd_write and cmd_read registers?

Code: [Select]
uint32_t cmdBufferWr= ft800memRead32(REG_CMD_WRITE);

sCommands.Instruction = 0x00;
sCommands.InstructionMode = QSPI_INSTRUCTION_NONE;
sCommands.AddressMode = QSPI_ADDRESS_4_LINES;
sCommands.DdrMode = QSPI_DDR_MODE_DISABLE;
sCommands.AddressSize = QSPI_ADDRESS_24_BITS;
sCommands.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
sCommands.AlternateBytesSize = QSPI_ALTERNATE_BYTES_8_BITS;
sCommands.AlternateBytes = 0x00;
sCommands.Address = (cmdBufferWr + RAM_CMD) | 0x800000;
sCommands.DataMode = QSPI_DATA_4_LINES;
sCommands.NbData = ulCommandIndex;
sCommands.DummyCycles = 0;
sCommands.DdrHoldHalfCycle = QSPI_DDR_HHC_ANALOG_DELAY;
sCommands.SIOOMode = QSPI_SIOO_INST_EVERY_CMD;

s_transfer_reg_to_ftdi.b_state = IMAGE_TRANSFERRING_FTDI;
__FTDI_SELECT();
vDelayUs(300);
HAL_QSPI_Command(&hqspi, &sCommands, HAL_QPSI_TIMEOUT_DEFAULT_VALUE);
HAL_QSPI_Transmit_DMA(&hqspi, (uint8_t*) &ucCmdBuffer[0]);
« Last Edit: July 27, 2018, 09:16:28 PM by gokhannsahin »
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 892
    • View Profile
Re: FT813 CRC calculating and adressing
« Reply #1 on: July 30, 2018, 03:11:46 PM »

Hi Gokhan,

For Q1,
Yes, some commands such as CRC and GetPtr use the RAM_CMD FIFO to return the result. In these cases, you should still respect the rollover and should not try to get the result from an address beyond the end of the FIFO.

When you write the command, send the parameters replacing any result fields with dummy 0h values of the same size (in this case, all 3 parameters are 32-bit values including the result). Whilst CS is low, FT8xx will wrap the data around at (RAM_CMD+4095). Your own MCU's count of the offset should also perform a wrap-around.
void cmd_memcrc( uint32_t ptr, uint32_t num, uint32_t result );

Then update the write pointer and await the pointers being equal i.e. REG_CMD_READ == REG_CMD_WRITE.

Once equal, check the ending address WritePointer = REG_CMD_WRITE    This would be the 12th address as you mentioned in this example. (4092 plus 4 byte command plus 12 bytes of parameter)

Now you can do a 32-bit memory read of address (RAM_CMD + WritePointer - 4) & (4095) and you will be going back by 4 bytes taking account of rollover and reading the result. Therefore, you would do a read of the 8th address as you mentioned.

The REG_CMD_READ and REG_CMD_WRITE would still be pointing at the 12th address. You would use a memread32 to retrieve the 32-bit result value beginning at the 8th address.

For Q2,
You should always use the buffer as a true circular buffer. You should start your 3012 bytes of command from the current pointer position and should not write them back to 0.

Do you use burst writes? (keeping CS asserted and streaming the commands)?

If so, as you stream the data, the FT8xx will wrap around internally at 4095 back to 0 and so the commands will stay within the buffer.

Your own MCU code should also perform the rollover so that you can write the correct value to REG_CMD_WRITE at the end of the new list. e.g. MCU would track offset as ((2048+3012) & 4095)

Best Regards,
FTDI Community
« Last Edit: July 30, 2018, 03:13:25 PM by FTDI Community »
Logged

gokhannsahin

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: FT813 CRC calculating and adressing
« Reply #2 on: July 30, 2018, 07:02:03 PM »

Thank you so much. It works as I want.

Yes, I use burst mode when to write the commands.(DMA) And I pay attention to the CS pin being low while transferring.
Well, once the transfer is completed, should I write manually the new cmd_write_reg value while using command buffer? Or it will update this register itself? For.ex. after transferred the commands of 3012, the following method is right?
Code: [Select]
uint32_t cmdBufferWr = ft800memRead32(REG_CMD_WRITE);
ft800memWrite32(REG_CMD_WRITE, cmdBufferWr + 3012);
ulCommandIndex = 0;

Also, sometimes REG_CMD_READ isn't equal to REG_CMD_WRITE. What can I do then? Should I reset the co-processor? If yes, I'm using the quadspi module and it has four lines while communicating the processor. After I send the reset command does it still keeps communicating 4 lines, or need to send the ft800memWrite8(REG_SPI_WIDTH, 0x02); again? Although the active_command is sent, it always is the black screen not turn the backlight on. Do it need the all command at the initializing again? The code is as the following;

Code: [Select]
ftcmdwrite4lines(RST_PULSE);
ftcmdwrite(FT_EXTERNAL_CLOCK);//or ftcmdwrite4(FT_EXTERNAL_CLOCK);
ftcmdwrite(COMMAND_ACTIVE);//or ftcmdwrite4(COMMAND_ACTIVE);
HAL_Delay(500);
//ftmemwrite8(SPI_WIDTH,2);
ftmemwrite8(PWM_DUTY,100);//it writes 4 lines

Furthermore, the images that are converted both ARG1555 and PALATTED4444 doesn't look right on the screen. The pixels of the image which is converted as ARGB1555 looks square. Lots of white pixels are looked while using the image which is converted as PALATTED444 on the screen (800x480). I would like to use a transparent image. Is there a method to solve these problems, different tool or format?
Logged

gokhannsahin

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: FT813 CRC calculating and adressing
« Reply #3 on: August 06, 2018, 02:29:27 PM »

I'm still getting the error while checking CMD_READ_COMMAND and CMD_WRITE_COMMAND. Please help me? And I would appreciate if you help me with my other questions?
Logged

FTDI Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 892
    • View Profile
Re: FT813 CRC calculating and adressing
« Reply #4 on: August 08, 2018, 11:58:18 AM »

Hi,

After adding commands or data to the co-processor RAM_CMD you must manually write the REG_CMD_WRITE to update it to point to the end of your data. In general, your application writes REG_CMD_WRITE and the co-processor writes the register REG_CMD_READ. Your MCU must keep an accurate count of the number of bytes sent and take account of the wrap around at RAM_CMD + 4095 (effectively it maintains an equivalent count to what the EVE device is doing internally)

If an error occurs, you should follow the steps shown in section 5.6 below:
http://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/FT81X_Series_Programmer_Guide.pdf
What cases do you see the pointers remain un-equal? The section mentioned above has some examples where it may happen such as an invalid image format, corrupted image, image de-compress where there isn't enough RAM_G space  to put the resulting data, a blocking call (such as calibrate), a command with invalid parameters (e.g. non multiple of 4 bytes) or it could be an error in the amount by which the MCU increments REG_CMD_WRITE.

For the transparent image, please ensure that the original one displays correctly in a program such as GIMP as the original image may have some non-transparent pixels (e.g. slightly different shade from the transparent colour) where you had expected transparency.

Regards,
FTDI Community
Logged

gokhannsahin

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: FT813 CRC calculating and adressing
« Reply #5 on: September 03, 2018, 07:23:07 PM »

Well, how to check the MCU whether has been reset? If the REG_READ and REG_WRITE registers are zero, does it mean that the chip has really been reset?
Logged

gokhannsahin

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: FT813 CRC calculating and adressing
« Reply #6 on: October 07, 2018, 03:08:58 PM »

Please help me! How can I know that it has been reset?
Logged