Hi,

I am trying the W25Q01JV flash with 1Gbit size and have problems while flashing. When I do a crc calucation after I wrote a sector (4K) I get errors on very specific sectors. All of them are the odd indices. F.e. Sector 0 (0-4095), sector 1 (8191) fails, the next one is successful again.
Just to show an example, those are the first few sectors which fail: 37, 43, 45, 67, 69, 73, 75, 77, 79, 97, 99
It seems to only happen, when I switch to FLASH_STATUS_FULL after writing the Blob. So I stopped to switch to FLASH_STATUS_FULL when writing on the flash.

But whenever I don't switch to FLASH_STATUS_FULL I cannot write more than 16 Megabyte. I get address errors back when using CMD_FLASHUPDATE (invalid address). This is the error I get when reading out RAM_ERR_REPORT:
illegal flash address in cmd_flashupdate()

This error I would usually get when my Flash would have a size of <= 16 Megabyte, but I am writing after that address. The BT chip seems to get the correct size, because I get "128" back for REG_FLASH_SIZE.

Is there a compatibility issue with that Winbond flash? I checked this list and did not find any flash with 1Gbit size, which I need: http://www.brtcommunity.com/index.php?topic=77.msg1658#msg1658

I also changed the flash on my board to make sure that it is not damaged, but had the issue with 4 different pieces. Do you have any suggestions how to debug that or any information if that Winbond flash has been tested by someone already?

Hello, I am successfully using the font cache of BT817, I can enable it for a specific font, use it and query the total and used numbers.
But when I try to disable the font cache (setting font for CMD_FONTCACHE to 255) the command cannot get processed (REG_CMD_READ does not reach the value of REG_CMD_WRITE, so I need to reset the co processor). There is no message in RAM_ERR_REPORT at that time.
In my specific case the REG_CMD_WRITE and REG_CMD_READ are both at 556. After sending the commands, I set REG_CMD_WRITE to 572 (command length is 16 byte).
I then wait for the REG_CMD_READ to reach REG_CMD_WRITE and I see that REG_CMD_READ stays at 556 forever but REG_CMD_WRITE changes to 256 after a short time. I do not know the reason for that, because I do not write anything to it. I just read constantly REG_CMD_READ and REG_CMD_WRITE.

I tried to set multiple empty display lists before and after the disabling of the font cache, so no current or display list is using any font, but I get the same behaviour.
While trying to find out the issue, I tested a few different values for the font in CMD_FONTCACHE and I can set any font <85. Every font from 85 on to 255 lets REG_CMD_READ stay at the last value.

For understanding, why I want to disable the font cache: I have some pages with a lot of text, where I want to use the cache, but other pages with bigger images, where I want to have as much of free RAM as possible.

UPDATE: I tested it with the same board but 3 different BT817 chips. 2 of them don't have that issue and they work fine. Just one of them has this issue. So I am really curious about, what could be the problem.

Hello, I am Trying to flash a new firmware for the capacitive touch controller. I am using the BT815 with the EVE Asset Builder 2.2.
I was not successfull with my code in the first place, I sniffed the I2C traffic between the BT815 and the touch controller and it did not address and send the correct data.
That's why I tried to simplify it by removing the whole I2C communication and just reporting static values to the BT815. This is the code I am compiling:
int i2c_addr()
{
  return 0x38; // does not matter for my test
}

int setup()
{
  setWAKE(0);
  delay_ms(5);
  setWAKE(1);
  delay_ms(300);
}

void loop()
{
report_touch(0, 400, 300);
delay_ms(5); // also tried without those delays and with id 1 as well
report_touch(0, 200, 100);
delay_ms(5);
}

which results in this:
26,255,255,255,32,32,48,0,4,0,0,0,2,0,0,0,26,255,255,255,0,176,48,0,4,0,0,0,5,2,0,0,34,255,255,255,238,178,48,0,120,218,37,142,177,75,195,80,16,198,239,154,182,168,25,204,251,3,58,60,16,165,24,39,59,56,222,209,69,40,217,197,233,189,182,70,180,89,156,20,117,184,172,18,72,157,197,81,40,205,191,32,14,78,29,187,56,73,233,226,238,232,34,196,151,56,220,241,187,143,239,227,59,101,246,233,78,31,66,102,148,163,54,237,152,107,62,35,207,118,38,55,184,43,3,80,166,79,222,80,153,92,191,16,92,62,96,110,67,167,30,72,150,108,186,129,24,197,27,53,229,17,143,36,51,247,46,239,11,36,202,38,188,103,79,185,51,241,157,247,137,127,1,177,199,61,222,16,239,42,31,130,204,120,206,43,66,153,97,197,129,157,51,242,10,124,137,160,74,67,12,18,88,20,24,45,180,178,39,220,167,192,54,169,37,112,254,174,111,233,24,202,18,98,111,220,149,1,109,59,247,22,125,232,174,68,53,127,234,204,148,238,159,37,66,186,100,101,214,85,227,197,26,209,93,95,216,168,55,200,148,91,82,184,246,41,135,105,1,175,236,148,52,76,159,107,21,100,33,99,249,231,55,252,230,31,142,210,130,218,141,63,227,110,93,240,0,0,26,255,255,255,32,32,48,0,4,0,0,0,0,0,0,0
But when I try to get the touch values (the raw ones from REG_TOUCH_RAW_XY) I just get x: 0, y: 0 or x: 65535, y: 65535.
I can see that the BT815 is not communicating via I2C anymore, so the transfer of the firmware seems to work at least in some parts.

I have also a few more questions:
- is the response of int i2c_addr() used over the one in REG_TOUCH_CONFIG (REG_CYA_TOUCH) or which one is priorized?

- is it possible to configure the I2C frequency?

For uploading the Firmware my code looks like this:
Gpu_Hal_WaitCmdfifo_empty(host);
Gpu_Hal_WrCmdBuf(host, TOUCH_DATA, sizeof(TOUCH_DATA));
Gpu_Hal_WaitCmdfifo_empty(host);
I tried it right after GPU_ACTIVE_M in setup and also after getting the BT815 ID via REG_ID.
I also tried to reset the touch component with Gpu_Hal_Wr32(host, REG_CPURESET, 2); followed by Gpu_Hal_Wr32(host, REG_CPURESET, 0);

The real code which I tried to compile and run at the first place is this one:
int i2c_addr()
{
  return 0x41;
}

int setup()
{
  setWAKE(0);
  delay_ms(5);
  setWAKE(1);
  delay_ms(300);
}

void loop()
{
  while (getINT() == 1) // wait for INT to go low
    ;
  i2c_startread(0x10);
  int n_touches = i2c_read8();
  int touch_index = 0;
  int x_raw;
  while (touch_index < n_touches) {
x_raw = i2c_read16le();
report_touch(touch_index, i2c_read16le(), x_raw & 0x3fff);
touch_index = touch_index + 1;
  }
  i2c_stop();
}
It would be nice, if there are some more information about updating the touch firmware or if someone could test the firmware on top to check if the uploading is the problem.
If it helps I can also provied sniffed I2C traffic of one of the compiled firmwares.