Hi,

We'll check if we have some examples, in the meantime we have a structure declared in our user guide which may be helpful,


struct EDF {
uint32_t block_length; // the length of this EDF
EVE_Flash_Asset_Info assets[0...n-1]; // the information of n assets
};

struct EVE_Flash_Asset_Info {
uint16_t assetID; // the sequential ID of the asset
uint32_t startAddress; // the offset of the asset
uint32_t size; // the size of the asset, in byte
uint8_t compressionMethod; // 0 = no compression, 1 = compressed
uint8_t type; // the type of the asset, see below
uint16_t subType; // the subtype of the asset, see below
uint16_t width; // the width of bitmap/video/animation
uint16_t height; // the height of bitmap/video/animation
};

Best Regards, BRT Community

Do you have a small example of an item in the Flash map file? Please provide the code you use to read it into RAM_G, as well as the code used to display it. We can help check if there are any issues.
Best Regards, BRT Community

Hi,

Great to hear that it is all working well now

Best Regards, BRT Community

Hello,

One way to do this would be to include a small file of your own in the flash build bin file when creating in EAB. The BT815 can read data from flash into RAM_G, which your MCU can then read via SPI and so you could check the value that has been read from Flash.

You can make the file a fixed size and allow space for other data if needed so that changes in it don't affect the addresses of other assets at later addresses.

For CMD_FLASHREAD the address is 64-byte aligned and so it is worth making your own version-info file to be aligned to 64 bytes.

Best Regards, BRT Community

Hi,

Thanks for the image, we'll try it out here too.

It is worth trying Rudolph's advice to use CMD_SETBITMAP -  if you set the size and layout via the individual commands and if the layout and size _H values (which have the upper bits) are left with old values then EVE may be using these incorrect values.

Also, displaying from RAM_G is good to test,

Best Regards, BRT Community

Hi,

Could you advise which model of display module that you have for each, and what display settings you use for each?
Normally for displays of different sizes and/or resolutions, you should still see content display correctly so long as the display settings registers are all set correctly for the display.

Also, are your fonts custom ones or are they stored in Flash as custom fonts?

Best Regards, BRT Community

Hello,

Glad to hear you have managed to mitigate the issue, please let us know if it happens again or you run into any more issues.

Best Regards,
BRT Community

Hello,

Thank you for the update.

Can I clarify if you are trying to use CMD_ROTATE or CMD_SETROTATE? the function name provided below implies the former, but the definition for the later appears to have been utilised.

There is no reason that the CMD_ROTATE or CMD_SETROTATE command would cause the co-processor to hang (REG_CMD_READ =/= REG_CMD_WRITE) in normal operation. but it would help to understand when you are trying to call this command and what you are trying to achieve by calling it. i.e. are you trying to rotate an image and inadvertently using SETROTATE or are you intending on rotating the full screen?

In any case a a co-processor hang can also be caused by a poorly formed SPI transaction being received by EVE, in this case it may still be worth checking the integrity of the QSPI signals to the BT81x. Could also confirm if you are still seeing intermittent rendering fails, and if these are mitigated by removing the call to TFT_qspi_cmd_rotate?

Best Regards,
BRT Community