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.

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?

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 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)?