BRT Community

Quote from: pauljiao on September 20, 2019, 03:14:07 AM
First, "CMD_FLASHDETACH â†' CMD_FLASHATTACH â†' CMD_FLASHERASE â†' CMD_FLASHFAST cycle"  is not feasible because after flash is erased

You're right. I fixed my post by adding an extra CMD_FLASHWRITE(unified.blob).

Quote from: pauljiao on September 20, 2019, 03:14:07 AM
Secondly,  at my side,  with your code logic, cmd_flashread can read the flash sector correctly
after cmd_flasherase is done.   The buffer is filled with 0xFF, not 0x55.

If your run the code again, what do you read? 0xFF or the older FLASH content?

In my test I didn't switch off the board, rather I started over and sent a RST_PULSE host command before accessing the FLASH again.

Hi everyone,

I noticed that working in full speed mode, attached FLASH in not actually erased. Application note BRT_AN_033 - BT81X Series Programming Guide, version 1.1, table at chapter 2.8 Flash Interface, states it's possible, though. I'm wondering if I'm making any mistake.

The following pseudo-code fills buffer with 0x55 and FLASH content is not wiped out (running the code again returns actual data over and over):

unsigned ram_g = 0xff00;
unsigned flash_addr = 4096
char buffer[256];

// FLASH contains proper unified.blob
flashfast();

flashread(ram_g, flash_addr, sizeof(buffer));
read_memory(ram_g, buffer, sizeof(buffer)); // buffer contains actual data

flasherase();

flashread(ram_g, flash_addr, sizeof(buffer));
read_memory(ram_g, buffer, sizeof(buffer)); // buffer is filled with 0x55


If I comment out the line with flashfast(), FLASH gets erased (process takes much longer) and buffer is filled with 0xff.

There's no counterpart to CMD_FLASHFAST, thus I believe one should go through the CMD_FLASHDETACH â†' CMD_FLASHATTACH â†' CMD_FLASHERASE â†' CMD_FLASHWRITE(unified.blob) â†' CMD_FLASHFAST cycle. I didn't experiment with it because I can live with writing FLASH at normal speed.

Thank to everyone. Working in full speed mode fixed my issue with CMD_INFLATE2.

Hi everyone,

I'm trying to wrap my head around CMD_INFLATE2. I'm always getting ERROR: corrupted DEFFLATE data in cmd_inflate2(). FLASH is in attached state and I can read/write to it in no-fast mode. No blob is present in the FLASH.

First of all, am I wrong in assuming that CMD_INFLATE2 reads the FLASH from an address given by CMD_FLASHSOURCE? Something like:

cmd_flashsource(flash_addr);
cmd_inflate2(ram_g, 64);

Secondly, which kind of flash_addr does CMD_INFLATE2 need? A physical address or a BITMAP_SOURCE-like one (i.e., 0x800000 | phy_addr/32)? Chapter 2.1 Addressing Space cites CMD_INFLATE2 when talking about Flash memory. Chapter 5.86 CMD_FLASHSOURCE â€" Specify the Flash Source Address doesn't say anything about address space.

Thirdly, what does CMD_INFLATE2 exactly do? Does it read data from FLASH and inflate them on-the-fly, writing the result to RAM_G? Or does it read from FLASH, write data to RAM_CMD, then command CMD_INFLATE to RAM_G?

By the way, byte₁ at page 115 starts at byte 12, doesn't it?

Thank you very much for the quick reply.

I imagine the same applies to other FLASH-related commands.

I believe a hint in the Application Note (at "Flash Interface" chapter?) would be helpful for other developers, too.

Hi everyone,

my NOR FLASH memory can take several seconds, almost a minute, to fully erase its content. How do I know the process is completed? I cannot find any register or interrupt flag for that.

Should I wait for REG_CMD_READ to catch up with REG_CMD_WRITE?

Thanks in advance.

I believe I found the culprit: myself. I didn't initialize the display list to any value before writing REG_PCLK. Now I send DISPLAY() and write REG_DLSWAP before REG_PCLK.

I think the behavior between FT813 and BT815 is different, though. I have never experienced any problem with my previous PCB.

I tested more PCBs and I doubt the problem lays in the configuration because different PCBs have different behavior: some fails, other works perfectly.  When turning the same PCB on and off several times, it may fail or not at random. It really looks a hardware issue to me.

I also made the following test. If I stop any SPI activity after setting PCLK, the BT815 start clocking and then stop on a failing PCB.

Is there any pin I should check (apart from PD_N)?

Hi everyone,

I've been successfully using FT813 in my project for the past 3 years (custom SPI protocol implementation). We'd like to move to BT815. New PCB then, but same code base: BT815 doesn't show anything on the LCD (backlight is on, though). Can anyone help out?

Checking with a logic analyzer, SPI bus levels seem OK. Is there anything special to pay attention to when initializing the FT813 or BT815?

What I find strange is that signal PCLK stops clocking after exactly 7340 periods. Every time. It starts as soon as REG_PCLK is written.

To me, it looks like BT815 tries to talk to the LCD but gives up.

Pin DE is disconnected, DISP is driven high.

Thanks,
Lorenzo