BRT Community

The SPI clock is actually 10 MHz, not 12 as previously stated.  That seemed reasonable, and I was considering increasing it since the FT813 can support up to 30 MHz.  However, due to the mechanicals of the system, the ribbon cable connecting the main board to the display looks like it's 16 to 18 inches.  I don't know what this translates to as far as a max SPI clock speed, but maybe 10 MHz is pushing the envelope.

I was going to run a test with a lower clock speed, but identified a separate problem/bug in the application firmware.  The code that initiates the SPI transaction to get touch tag was not checking the return code from the SPI library call that executes the transaction; it just set the flag indicating that a tag had been read and thus no longer available to read.  The application was locking up on a particular screen, and when it stopped responding to touch, the interrupt was firing, the flags indicated a new touch tag was available, but there was no SPI transaction to read the tag, even though that code is executed unconditionally.  This indicated a failure in the SPI library call (this is on an NXP RT1064, by the way).  I moved the line of code that cleared the touch tag available flag to the point where the call had to have succeeded, which will force a retry on failure.  I could not reproduce the lockup scenario after making this change.

What's peculiar about this is that I was also no longer able to reproduce the 300 ms gap when refreshing the main screen, but that has nothing to do with touch tags.  I'm wondering if moving around the cable to check length affected performance somehow.  These issues do appear to be related to the SPI port at the micro.

With regard to the interrupt handler, it does not include any SPI transactions.  The concern was that an interrupt could occur in the middle of sending commands to the coprocessor in preparation for updating the display.  The interrupt handler just sets a flag indicating that an interrupt has occurred, and the application idle loop picks up on that and reads the interrupt flags when the command coprocessor is idle.

I am going to continue to test, and will post logic analyzer logs along with images if I see issues.

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.

[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.