Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - lorcap

Pages: [1]

Discussion - EVE / Erasing FLASH in BT815's full speed mode

« on: September 18, 2019, 10:00:34 AM »

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

Code: [Select]

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.

Discussion - EVE / Loading images with CMD_INFLATE2

« on: September 13, 2019, 04:36:47 PM »

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:

Code: [Select]

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?

Discussion - EVE / How to detect CMD_FLASHERASE completion?

« on: September 10, 2019, 10:11:07 AM »

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.

Discussion - EVE / BT815's PCLK stops clocking after 7340 periods

« on: May 27, 2019, 12:53:35 PM »

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