MAX78000FTHR and Ada 2.4" display

[berrystephenw]

Apologies if this doesn't belong here, there appears to be no support yet on ADI for this design.

I have a MAX78000 feather and an ADAfruit 2.4" TFT display. I am able to compile and run the demos on the MAX78000 board but I am unable to get the TFT display to do anything at all - except turn on the backlight. I know the display is working correctly because I have an Adafruit ESP board that runs example display demos without a problem.

My environment is the latest master branch of the msdk, linked to the toolchain. Any help is appreciated.

[Jake-Carter]

Hi @berrystephenw, does your TFT happen to be the "V2" version?

I see that the design has changed, and the V1 version has been deprecated. The primary change seems to be updating the touchscreen controller from the STMPE610 to the TSC2007. (See V1 schematic vs V2 schematic), but there may be other changes we need to account for as well

[berrystephenw]

Yes its a V2, I bought it recently and they no longer sell the V1 to my knowledge.

Is there anything I should look for in the initialization code that would cause the display not to function? The touchscreen doesn't control the backlight anymore - looks like it is always on in the new design.

[Jake-Carter]

I took a look at our drivers and unfortunately they don't do any error checking... I tested them with my FTHR with no display connected and they just plow through like nothing's wrong.

if you haven't already, it'd be worth checking the project settings. Some require you to explicitly enable the TFT display code (ex facial_recognition). I didn't see any glaring hardware changes specific to the ILI9341 connections. Just want to throw out the obvious things first.

Digging in - the first thing I would add is a verification of the display ID info (see pg 91 of the datasheet). It should be added to displayInit here to validate the SPI communication is fundamentally working. The datasheet doesn't mention what the expected values are. If you'd be willing to pull them out with your ESP board and post them here that would be very helpful.

Beyond that, the rest of the initialization sequence is full of un-commented magic numbers, but is known to work for V1.

The biggest blocker here is that the drivers appear to be write-only... They need a refactor to support reading out the ID register. If you're willing to do some assisted hacking of the drivers to insert that ID check it'd help narrow down the issue further. Otherwise it'll probably be at least a week until we can get ahold of a V2 display and start work on updating them

[berrystephenw]

Hi Jake - I did find the project setting for facial-recognition to turn on the TFT, and when the display didn't work I switched to the TFT_Demo to just focus on the display portion.

I'll look through the Arduino code and see if I can pull the ID out of the module. There may be other clues in the init there as well.

Thanks for the help !

[berrystephenw]

Check out page 187, looks like there is a shadow ID register with expected values. I'll see if I can verify both registers on the ESP.

[berrystephenw]

I modified 'graphicstest_featherwing' in the Arduino IDE to print out the ID register. Unfortunately the ID register 0x04 gave up only zeros.

Register ID4 however returned the correct info

  x = tft.readcommand8(0xD3);
  Serial.print("Read ID4: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(0xD3,1);
  Serial.print("Read ID4: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(0xD3,2);
  Serial.print("Read ID4: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(0xD3,3);
  Serial.print("Read ID4: 0x"); Serial.println(x, HEX);

Read ID4: 0x0 Read ID4: 0x0 Read ID4: 0x93 Read ID4: 0x41

[berrystephenw]

Link to the Adafruit init/read code - very interesting comment on the reads Adafruit_ILI9341.cpp

/**************************************************************************/
/*!
    @brief  Read 8 bits of data from ILI9341 configuration memory. NOT from RAM!
            This is highly undocumented/supported, it's really a hack but kinda
   works?
    @param    commandByte  The command register to read data from
    @param    index  The byte index into the command to read from
    @return   Unsigned 8-bit data read from ILI9341 register
 */
/**************************************************************************/
uint8_t Adafruit_ILI9341::readcommand8(uint8_t commandByte, uint8_t index) {
  uint8_t data = 0x10 + index;
  sendCommand(0xD9, &data, 1); // Set Index Register
  return Adafruit_SPITFT::readcommand8(commandByte);
}

[berrystephenw]

@Jake-Carter I've tried a few more things: I rewrote the init code to emulate exactly what Adafruit does for initialization - there are differences that don't match the data sheet with writes to registers that don't seem to exist. This did not change anything.

Second, I started to suspect my hardware so I ohm'd out all the connections between the LCD and the 78000 feather. All good. Lastly, I pulled out a scope and looked for activity the SPI bus. TFT_DC toggles, TFT_CS remains high for the test.

However - there is no activity at all on the SCLK, MOSI, MISO lines. They are all floating high with a bit of ripple around 3V.

I'll dig around the SPI initialization stuff and see if anything has changed recently - if you have any pointers that would be helpful.

[Jake-Carter]

Thanks @berrystephenw this is vert helpful. Strange tou're not seeing any activity. One immediate thing you can try is flipping this definition here (https://github.com/analogdevicesinc/msdk/blob/c7dc24619e995f17cefd9c776292d318a8a04afb/Libraries/MiscDrivers/Display/tft_ili9341.c#L50).

That'll switch to using our usual SPI blocking function for the transmit instead of the custom register-level implementation.

The VSSEL logic sets 3.3V, and the SPI init routines seem normal. Doesn't look like there's pull-ups or anything weird on the SPI bus... I'll do some more digging into the software as well

[berrystephenw]

Ok I've got it working - so don't bother doing any more research.

Part of the problem was my SD card wasn't being recognized for the face recognition - now that demo is working after a format.

The TFT demo is still not working, but I think I might know what that is. I'll try a couple more things and then we can close this as a non issue.

[berrystephenw]

So this is where I am now - I have three copies of the MSDK and I open the folder for the facial_recognition demo in each:

1. Feb 12th I downloaded from github the MSDK as a zip.
2. current main MSDK - used github desktop to grab this one recently.
3. MAXIM installation copy

The MAXIM_PATH variable points to the #2 install "C:/Data/msdk" in each example. I'm using VSCode.

The only version that works is the Feb 12 MSDK facial_recognition demo. The other two give me errors reading the SD filesystem when running the facial_recognition demo. TFT_Demo does nothing on all of them. I do a clean/clean peripherals/build/flash run each time.

So essentially the current libraries, older example works but the current libraries current example does not. This isn't making any sense to me...

[Jake-Carter]

The latest example uses FatFS R0.15, whereas the older example uses FatFS R0.13. This is selected using the FATFS_VERSION build config variable.

What is the type, brand, and size of the SD card you're using?

R0.15 comes with exFAT support for SDXC cards, but it requires more system resources. For that example, I disabled exFAT via a custom ffconf.h inside the project. In testing, I saw failures to open the "weights_2.bin" file if LFN was disabled. But that should be fixed in the latest example, as LFN is enabled.

Which FatFS function is failing? There may be another issue with R0.15 that we have not seen in our testing.

[berrystephenw]

I'm using a Sandisk Extreme 64GB A2 SD. It was an exFAT FS.

I'll try to recreate the problem here (different laptop) and send you the messages. From memory it was a no filesystem error.

[berrystephenw]

I updated the tools (maintenance tool), downloaded the latest main branch and flashed the board:

Then I changed the flag #define FF_FS_EXFAT 1 // was 0

and now the demo works!

[Jake-Carter]

Perfect! Yep anything above 32GB is an SDXC which requires exFAT. I've got that disabled by default for that demo since for some previous builds it was running out of SRAM. I'll go ahead and close this out since it sounds like the V2 TFT works as well. Thanks for the info on the ID registers!

Let me know if you have any other issues or questions, especially as you get deeper into evaluating the CNN accelerator. My email is jake.carter@analog.com if you want to reach out direct