Please attach logfile from your logic-analyzer, there really is not much to see in these images.
Not that I am expecting to see anything at 12MHz, but there is not really much to analyze with these images.

Hello,

On the programmers guide point, this is currently going through the final review stages and we hope to have it released shortly.

I will follow up with the R&D team for your other queries.

Best Regards,
BRT Community

Hello,

Thank you for the update and the details.

I had a quick discussion with the R&D team concerning the operation of the of REG_INT_FLAGS, REG_INT_MASK, and the INT_N pin in general. After viewing the associated microcode I can note that the  REG_INT_FLAGS register is always set by hardware, however, the INT_N pin is only asserted to low when the corresponding bit of REG_INT_MASK is enabled. In this case it may be possible to some values from the REG_INT_FLAGS register that hadn't previously been set in the masking stage.

However, in believe in this case that the 0x4A you are reading from the register should likely be 0x25 (SWAP, TAG, FIFO empty). It is possible that there may be a hardware related issue causing this, one approach would be to test the register reads using a slower SPI clock rate as Rudolph has suggested. But, I would be interested to know in the first instance if the ISR has any bearing on the behaviour you are seeing. Would it be possible to test the ISR where you only perform a read of the REG_INT_FLAGS register on the INT_N pin toggling? and do not service the routine or send any new commands to EVE otherwise. I'm curious to see if the 0x4A register read still occurs in this instance.

Best Regards,
BRT Community

Any ETA on an updated BT82x programming guide?

A few answers to the more crucial questions I posted would be very nice beforehand.
Like how REG_LVDSTX_PLLCFG actually works - if the guide is wrong there and I am not using the register incorrectly...


And I have a new question.
Is there a way to check if rendering of a display list is done?
Well yes, I could read REG_RE_RENDERS and check for a change.
But this takes a bit of caution and requires to not into a deadlock.
Or I guess using CMD_GRAPHICSFINISH could work, reading REG_CMDB_SPACE after this should indicate that the co-processor is waiting for the render engine to finish.
Hmm, sounds like a plan, I maybe should always end the BT82x display list with CMD_GRAPHICSFINISH and not send a new display list when the co-processor is still busy.

Well yes, there might be other things to do for the co-processor while the render-engine is busy, like loading assets or using CMD_TEXTDIM, in that case ending the display-list with CMD_GRAPHICSFINISH might be a bit inefficent, perhaps, especially when the render engine needs a bit more time than usual.

Interrupts are configured by writing 0x05 to REG_INT_MASK, then writing a 1 to REG_INT_EN.

Logic analyzer traces are attached.  I don't have the greatest logic analyzer, so the clock appears a little inconsistent (clock speed is 12 MHz).  The clock line is the top line with MISO below.  This is the pattern on each occurrence of invalid flags.  There is also a trace of a series of 100 ms updates showing the 300 ms gap when the flags are incorrect.

The screen manager is very basic; there is no screen stack involved.  It includes an active screen variable that gets updated based on user input on each screen.  The touch tag handler within each screen can update the active screen variable as necessary.  The active screen value directs touch tags received to the user input handler for the screen currently displayed.  It may be that I need a more reliable way to determine that a screen update is actually complete.  Accessing the SPI bus to read interrupt flags or touch tags is blocked when the application starts writing out screen commands to the command coprocessor, and is then allowed after the swap interrupt occurs.  The 300 ms timeout is a hack I had included early on, and needs to be removed and replaced with a better-thought out recovery mechanism if something goes wrong.

I can get with the hardware guy to discuss layout and pin configuration to see if there could be any issues with reflection or other hardware-related issue.

With some further testing I can check off a few questions:

*The offset of REG_SPI_WIDTH is 0x188 (the programming manual (v2.1) incorrectly states it is 0x180)
*You can write to the register using just 8 bits despite the manual indicating it's a 32 bit register
*This does appear to take effect once CS is released

So I really only have one outstanding question which is whether or not the SPI mode can be switched from normal to dual/quad at any time or if there is only a certain window during which this can take place.

I'm having trouble getting dual SPI mode to work. I've got some test code stood up that first reads REG_SPI_WIDTH which returns 0 as expected. I then try to set bit 0 to 1 using a write command, but this does not seem to take. I've verified this two ways:

* Read REG_SPI_WIDTH again to see if the new setting is in effect (this always returns 0) reading in both normal and dual SPI modes
* Read chip ID to see if it can be read back. No matter what I get the correct ID reading it in normal mode which suggests the setting has not taken effect

When exactly does the change take effect? I assume after CS is released? Does this register need to be handled as 32 bits or 8 bits? What is the correct offset for REG_SPI_WIDTH? 0x188?

The following code example is for the ESP-IDF.


#define REG_SPI_WIDTH        0x00302188
#define MEM_WRITE 0x80

static const uint8_t rxBits = 32;
trans.addr = REG_SPI_WIDTH;
trans.length = 0;
trans.rxlength = rxBits + dummyBits; //default to same as length
trans.tx_buffer = NULL;
trans.rx_buffer = rxBuf;
ret = spi_device_polling_transmit(EVE_spi_device, &trans);
assert(ret==ESP_OK);

uint32_t regSPI = 0;
memcpy(&regSPI, rxBuf+1, 4);
printf("%x\n", regSPI);

// write new register value, I've considered MSB and LSB encoding for these with no observed differences
trans.tx_data[0] = 0x1;
trans.tx_data[1] = 0x0;
trans.tx_data[2] = 0x0;
trans.tx_data[3] = 0x0;

trans.addr = REG_SPI_WIDTH | (MEM_WRITE << 16);
trans.length = rxBits;
trans.rxlength = 0;
trans.tx_buffer = NULL;
trans.rx_buffer = NULL;
trans.flags = SPI_TRANS_USE_TXDATA;
ret = spi_device_polling_transmit(EVE_spi_device, &trans);
assert(ret==ESP_OK);

trans.addr = REG_SPI_WIDTH;
trans.length = 0;
trans.rxlength = rxBits + dummyBits;
trans.tx_buffer = NULL;
trans.rx_buffer = rxBuf;
trans.flags = 0;
//trans.flags = SPI_TRANS_MODE_DIO;
ret = spi_device_polling_transmit(EVE_spi_device, &trans);
assert(ret==ESP_OK);

memcpy(&regSPI, rxBuf+1, 4);
printf("%x\n", regSPI);


This is occurring after initialization and after fast flash has been enabled.

Edit: I did another test where I switched to dual SPI shortly after the check of REG_CPU_RESET during initialization and this seems to have worked. Is it not possible to switch SPI modes at some point?

Just a thought, what is your SPI clock and have you tried to reduce it while reading?

In my experience, writing to EVE works a whole lot faster reliably than reading does.
And then there is driving the lines thru at least two connections of a FFC, depending on the layout,
the host mcu and the settings for the pins, SPI_CLK might not be looking so good and there might be reflections.

Hello,

Thank you for your question.

Can I ask how you have configured the interrupts?

Would it also be possible to provide a logic analyser capture of a read of the flags register when the issue occurs?

The interrupt flags not returning as expected is curious, but it would not be considered a fault scenario on its own.

Just to clarify you would only need to perform a fault recovery if the REG_CMD_READ register reports a value of 0xFFF (indicating a fault in the co-processor). In terms of EVE and the touch engine, the current valid display list contained within RAM_DL, will be read by the touch engine for tagged items, which will then updated the REG_TOUCH_TAG register if an item has been touched accordingly. In this sense as you have noted your screen manager is out of sync with what it believes to be on the screen, what is the mechanism, that you are using to keep track of screens in your application?

Best Regards,
BRT Community

[Originally posted to FTDI Community; was directed to move post to here]

We have a system using the FT813 display controller with a Newhaven display and capacitive touch screen.  At startup, the firmware configures the FT813 to enable touch tag changed interrupt and the swap complete interrupt, so the flags enabled are 0x05.  The main screen of the application updates every 100 ms.  Logic analyzer traces show the interrupt input from the FT813 to the host microcontroller going active, followed by the host firmware reading the interrupt flags.  Ordinarily this works fine, and the FT813 reports SWAP complete after the screen contents have been delivered to the command coprocessor and the swap command is executed and completed.  (Incidentally, Command FIFO Flag / CMDFLAG is also set.)

Intermittently, though, the interrupt flags returned are 0x4A, which indicate sound effect ended and touch detected, but the application does not use sound, the screen is not being touched, and none of these interrupts were enabled by the host firmware.  The timing of the interrupt is the same as if the screen swap has actually completed, but the swap interrupt flag is not set, so the application is not sure it's safe to write a screen update, and does nothing in response to that interrupt.  At this point in the evolution of this application, it just times out and resumes writing updates to the command coprocessor, and everything proceeds normally for a while, but this condition does pop up from time to time.

In earlier application firmware versions, it was (needlessly) rewriting the screen contents to the command coprocessor as soon as the swap was complete.  With this firmware, these errant interrupt flags were reported intermittently, but much more frequently.

My question is whether this indicates some sort of fault condition not listed in the documentation.  There are scenarios where screen content could actually change every 100 ms, so we would like to keep the capability of using this update frequency.  If the application sees this condition, should it go through the fault recovery procedure?

This does not cause a problem if the main screen is just sitting there updating with no user interaction, but when navigating from the main screen and between any of the other screens, the device can eventually stop responding to touch.  I have found that at least one cause of this is that the FT813 thinks one screen is displayed, while the screen manager in the application thinks it has moved to a different screen.  Touch interrupts are occurring, but the touch tag belongs to the wrong screen from the screen manager's perspective.  I'm wondering if this interrupt flag issue could be a cause for the application to get out of sync with the display controller, and so the application needs to treat the invalid interrupt flags as a fault condition.