Hello,

Thank you for the update.
Yes it is possible that a slight hardware issue with the SPI signals may be causing the issue with the co-processor.
Please let us know if you have any further issues.

Best Regards,
BRT Community

Hello,

Thank you for your question.

Please see section 5.7 of the programmers guide:
https://brtchip.com/wp-content/uploads/Support/Documentation/Programming_Guides/ICs/EVE/BRT_AN_033_BT81X_Series_Programming_Guide.pdf

This covers how to read co-processor faults, which would help use determine if this is the cause of the screen issues you are seeing. It also includes the recommended recovery procedure  for when a fault is detected.

Best Regards,
BRT Community

Hi,

We have not tried this particular one but we have used a similar technique with the ILI9488 in our ME810A-HV35R displays. In that case we use the same lines for SCK/MOSI/MISO for the display and for EVE but we have a second chip select and a DCX line for command/data selection for the display.

You can get an example of the hardware in the ME810A-HV35R datasheet.
https://brtchip.com/wp-content/uploads/Support/Documentation/Datasheets/ICs/EVE/DS_ME810A_HV35R.pdf

We also have a draft of an example which configures it, if you would like a copy then please email us at support.emea@brtchip.com and we can send you a beta copy,

The actual commands and values needed over this interface may vary between displays but the manufacturer will often be able to recommend a command sequence to set it in RGB mode etc.

Best Regards, BRT Community

Hello,

Thank you for providing your initialization code.
Could you try adding a 20ms delay after you have sent the host command to select the clock source?

In general, no it is perfectly acceptable to use the internal clock on the BT81x, and as far as I am aware there are no limitations when using the internal clock vs an external crystal. But I will double check this with the hardware team for you.

We have previously used the following Abracon Crystal on our BT81x development boards:
MFP#: ABM8G-12.000MHZ-18-D2Y-T
DigiKey Part # : 535-10261-1-ND

For your given crystal I would go with what the datasheet notes for the load capacitors, could you link its datasheet?
Also would you be able to attach the crystal section of your schematic?

Best Regards,
BRT Community

Hello,

Hello

I took screenshots from a logic analyzer of the following code

Code: [Select]

  delay(100);
  Serial.println(GD.rd(REG_FLASH_STATUS));
  GD.cmd_flashdetach();
  Serial.println(GD.rd(REG_FLASH_STATUS));
In the attachments, GD.rd(REG_FLASH_STATUS).JPG shows the logic when I send   Serial.println(GD.rd(REG_FLASH_STATUS));

and GD.cmd_flashdetach().JPG shows the logic when I send GD.cmd_flashdetach() and Serial.println(GD.rd(REG_FLASH_STATUS)) after that.

I noticed there is some random logic after I send Serial.println(GD.rd(REG_FLASH_STATUS))
The logic analyzer reads B0 81 CC after reading the REG_FLASH_STATUS and I don't know why that is.

Here is the layout of my GD.rd() function

Code: [Select]

byte GDClass::rd(uint32_t addr) {
  return GDTR.rd(addr);
}

Code: [Select]

  byte rd(uint32_t addr)
  {
    __end(); // stop streaming
    __start(addr);
    SPI.transfer(0);  // dummy
    byte r = SPI.transfer(0);
    stream();
    return r;
  }

Thanks for the screenshots, it looks as if the registers is being read correctly.
And the CMD_FLASHDETACH command does also seem to being written correctly.

The B0 81 CC is the RAM_CMD address that the CMD_FLASHDETACH command is being written to (0x3081CC, with the write bit enabled). This would indicate you have sent several other co-processor commands before issuing the CMD_FLASH command. It also appears if you are writing some display list commands into RAM_CMD immediately after reading REG_FLASH_STATUS for the second time.

Would it be possible for you to minimise the number of co-processor calls before attempting to send the CMD_FLASHDETACH command? And if possible could you implement a method similar to below to await the command FIFO executing the command before attempting to read REG_FLASH_STATUS again?

uint8_t HAL_WaitCmdFifoEmpty(void)
{
uint32_t readCmdPointer;

// Wait until the two registers match
do
{
// Read the graphics processor read pointer
readCmdPointer = HAL_MemRead32(EVE_REG_CMD_READ);

} while ((writeCmdPointer != readCmdPointer) && (readCmdPointer != 0xFFF));


if(readCmdPointer == 0xFFF)
{
// Return 0xFF if an error occurred
return 0xFF;
}
else
{
// Return 0 if pointers became equal successfully
return 0;
}
}
This should ensure the command has executed in the co-processor before you attempt to read what hopefully should be an updated register.

Also thank you Rudolph for giving that a try, his suggestion of calling CMD_FLASHSPIDESEL may also be useful in your scenario.

Best Regards,
BRT Community

Hello,

Yes this is impossible with the FT900 due to the number of USB Device endpoints available.

The previous post was written before checking the number of endpoints available.

Best Regards,
BRT Community

Hello,

Thank you for your question.
The W25Q128JVSIQ datasheet notes to read the Device ID of the flash chip, you must issue and instruction code to the IC “90h” followed by a 24-bit address (A23-A0) of 000000h. After which the Device/Manufacture ID is clocked out by the IC.

Unfortunately in this case it will not be possible to use the CMD_FLASHREAD and CMD_FLASHWRITE commands to access the Device/Manufacture ID of the flash IC. Currently it looks like your code is just reading a blank sector of flash.

I would suggest looking at the CMD_FLASHSPITX and CMD_FLASHSPIRX commands (only available after issuing a CMD_FLASHDETACH command), these should allow you to issue the correct opcode to the flash IC to retrieve the Device/Manufacture ID.

Best Regards,
BRT Community