I was sending CMD_FLASHDETACH() without the B0 25 78 in the screenshot attached.
Which references [ 302578h REG_CMDB_WRITE ] in BT817. Doing this is not discussed in the programming manual, so how are programmers supposed to know?
Well, I am doing this for a couple of years now which makes it difficult to see this with the perspective
of someone who has not. :-)
It is all there in the programming guide but perhaps a bit much alltogether.
Okay, there are several layers and you probably got most of this sorted out already.
But maybe this will help you a litte bit and maybe a little more when others come across this.
At the very base EVE only has three functions, Host Memory Read, Host Memory Write and Host command.
The first two bits on the SPI tell EVE what is what.
00 - Read
10 - Write
01 - Command
Read and Write are followed by a 22-bit address with the most significant bit first.
Command is followed by 6 bits for the actual command and two bytes for parameters.
So apart from a handfull of basic commands like ACTIVE, CLKEXT, PINDRIVE and so on,
everything is done by writing to or reading from EVEs memory.
The memory map shows these regions and give a hint for their purpose.
The main regions are RAM_G, which is our graphics RAM, RAM_DL which is where the display-list commands are written to, RAM_REG for the registers and RAM_CMD to which
coprocessor commands needs to be written so that the co-processor can execute them.
Chapter 1.4 of the BT81x programming guide has an API reference.
There are memory read/write functions.
The cmd() and cmd_*() functions write to RAM_CMD.
The dl() functions are the ones that are executed in RAM_DL.
And host_command() functions are just that.
So, my library is not writing the commands to RAM_CMD, it is writing all commands to REG_CMDB_WRITE instead.
This register was introduced with the FT81x and it really makes things less complicated.
In a nutshell everytime a 32 bit word is written to REG_CMDB_WRITE it is written to the next position in RAM_CMD.
The coprocessor commands written this way are executed automatically.
And you can write almost 4k, the size of RAM_CMD, as one stream of 32 bit words with only sending the address of REG_CMDB_WRITE at the beginning.
My library is also not writing to RAM_DL, it uses the coprocessor to do that.
Letting the coprocessor build the display list is a lot easier and quicker, all the widgets like CMD_TEXT or CMD_BUTTON are coprocessor commands and the coprocessor generates quite some amount of display list commands depending on the widget.
Since I was reading the correct REG_FLASH_STATUS with your library, I decided to copy your code and try it.
I made some adjustments and here is the code I used
EVE_cmd_flashdetach();
EVE_cmd_flashspidesel();
uint8_t tx_data[] = {0x90, 0, 0, 0, 0, 0};
EVE_cmd_flashspitx(4, tx_data);
EVE_cmd_flashspirx(0x00, 2);
EVE_cmd_flashspidesel();
Serial.println(EVE_memRead8(0x00));
When I run it. The serial monitor doesn't show anything and It seems like the code is getting stuck at EVE_cmd_flashspirx(). This function keeps doing something and is preventing the rest of the code from executing.
When I comment it out, the rest of the code executes.
What did you adjust and what does the rest of the SPI look like?
If you look at my basic example, I have this in TFT_init():
void TFT_init(void)
{
if(EVE_init() != 0)
{
tft_active = 1;
EVE_memWrite8(REG_PWM_DUTY, 0x30); /* setup backlight, range is from 0 = off to 0x80 = max */
touch_calibrate();
EVE_cmd_flashdetach();
EVE_cmd_flashspidesel();
uint8_t tx_data[] = {0x90, 0, 0, 0, 0, 0};
EVE_cmd_flashspitx(4, tx_data);
EVE_cmd_flashspirx(0x000f5000, 2);
So after EVE_init() the display is up and running with an mostly empty display list.
The next thing my code does is to fully initialize the flash and read from it,
follwed by writing image data to RAM_G.