Touchscreen setting on custom board (STM32F7 MCU)

[enia ami]

Posted on February 17, 2017 at 15:37

Hi,

I have a custom board based on the STM32F769IBIT MCU. I want to implement a BSP layer as there are with ST discovery boards. 

I've already implemented the SDRAM, the flash and the LCD (densitron 

84-0226-000T) but I'm struggling with the touchscreen which is the same one as mounted on the stm32f746g disco (

ft5336 Focaltech).

But I get an error for the TS whereas I'm using the ST init sequence. It seems to be that the TS is not detected or does not 'respond'. 

Here is the sequence I use to init the TS and where I've found the error :

#define TS_I2C_ADDRESS                   ((uint16_t)0x70)

uint16_t TS_Init(uint16_t ts_SizeX, uint16_t ts_SizeY)

{

// variables init

/* Read ID and verify if the touch screen driver is ready */

  ft5336_ts_drv.Init(TS_I2C_ADDRESS); // no error returned , see the init strucs below

  if(ft5336_ts_drv.ReadID(TS_I2C_ADDRESS) == FT5336_ID_VALUE)

  {

     // instructions

    status = TS_OK; 

  }

  else

  {

     status = TS_DEVICE_NOT_FOUND; //the returned error

  }

  return status; //

TS_DEVICE_NOT_FOUND is returned

}

When I dig for the function that returns the error, I found this one :

HAL_StatusTypeDef I2C_WaitOnTXISFlagUntilTimeout(I2C_HandleTypeDef *hi2c, uint32_t Timeout, uint32_t Tickstart)

and more prcisely, inside of it :

/* Check if a NACK is detected */

if(I2C_IsAcknowledgeFailed(hi2c, Timeout, Tickstart) != HAL_OK)

    {

      return HAL_ERROR;

    }

It seems that a NACK (Not ACKnowledge) flag is detected. 

The init seq (called by

ft5336_ts_drv.Init(TS_I2C_ADDRESS)) 

:

i2c_handler->Instance              = I2C2;

i2c_handler->Init.Timing           = (uint32_t)0x40912732;

i2c_handler->Init.OwnAddress1      = 0;

i2c_handler->Init.AddressingMode   = I2C_ADDRESSINGMODE_7BIT;

i2c_handler->Init.DualAddressMode  = I2C_DUALADDRESS_DISABLE;

i2c_handler->Init.OwnAddress2      = 0;

i2c_handler->Init.GeneralCallMode  = I2C_GENERALCALL_DISABLE;

i2c_handler->Init.NoStretchMode    = I2C_NOSTRETCH_DISABLE;

__HAL_RCC_GPIOB_CLK_ENABLE();

__HAL_RCC_DMA1_CLK_ENABLE();

/* Configure I2C Tx as alternate function */

gpio_init_structure.Pin = GPIO_PIN_10;

gpio_init_structure.Mode = GPIO_MODE_AF_OD;

gpio_init_structure.Pull = GPIO_NOPULL;

gpio_init_structure.Speed = GPIO_SPEED_FAST;

gpio_init_structure.Alternate = GPIO_AF4_I2C2;

HAL_GPIO_Init(GPIOB, &gpio_init_structure);

/* Configure I2C Rx as alternate function */

gpio_init_structure.Pin = GPIO_PIN_11;

HAL_GPIO_Init(GPIOB, &gpio_init_structure);

/*** Configure the I2C peripheral ***/

/* Enable I2C clock */

__HAL_RCC_I2C2_CLK_ENABLE();

/* Force the I2C peripheral clock reset */

__HAL_RCC_I2C2_FORCE_RESET();

/* Release the I2C peripheral clock reset */

__HAL_RCC_I2C2_RELEASE_RESET();

As you cas see, at this point the INT pin is not configured. 

Also, I don't know what should be the behaviour of the RST as there is no mention of it in the ST code.

If you have any suggestion, it would be much appreciated.

thank you.

[hbarta]

Posted on February 18, 2017 at 16:44

I presume you've stepped through the driver and looked at the return codes and determined that the operations are timing out. I also assume that you've tried reducing the baud rate to see if that helps. (It has never helped me but seems like a logical thing to try.) Edit: Just reread your post. Did you step through 

I2C_IsAcknowledgeFailed() 

to see if a NACK is received or if the operation timed out? A timeout could indicate a H/W issue whereas receiving a NACK would seem to point to sp,ething in the command stream that the touch controller does not like.

The thing that gets me most often with I2C devices is the addressing nomenclature. It's worth a try using the given address/2 or given address*2 to rule out that kind of problem. (That _has_ helped me in the past.

🙂

 )

Have you otherwise checked out the H/W?  Can you scope the signals to see if they are as expected? Having something like a Saleae or Beagle protocol analyzer is invaluable and can pay for itself in time saved when working out issues like this.

[enia ami]

Posted on February 20, 2017 at 14:22

Thank you for the answer.

I scope the signals and they are as expected, except for the Ack bit which suposed to be at a low level. Here, it's in a high level which means the indicated slave address doesn't respond. This beahviour is confirmed on the software side where the NACK is received. As you suggested, I tried the bit shifting on the slave adress but didn't work, the Ack bit still get high.

Maybe it's the slave adresse the problem ? In the ft3336.h file, it's clearly indicated '0x70'. I Checked on internet and it's the only address I found for this touchscreen.

Another source of problem could be the wake up / int signal and the powerup sequence but I assume it's handled by the device itself, isn't it ?

[hbarta]

Posted on February 20, 2017 at 15:21

I found a data sheet (

http://www.newhavendisplay.com/appnotes/datasheets/touchpanel/FT5336.pdf

 ) and it does describe power on and power cycle requirements so I would not assume that the chip handles this internally. (Based on a quick look at the data sheet. I have not studied it as I'm sure you have.)

Other possibility - cold solder joint? Chip damaged during assembly by excess heat? I hate to point to H/W but I recently spent two weeks trying to get something working until I tried a different board and everything worked perfectly. It turned out the chip on some boards had been damaged by excess heat during assembly.

It's useful to be able to drive reset and power signals via GPIO outputs for situations like this. S/W can then reset or apply proper power up sequence once board supplies have stabilized. Or reset the chip if it gets stuck. 

From the data sheet: 'INT signal will be sent to the host after initializing all parameters and then start to report points to the host.' Do you see this signal changing which would indicate the chip is working?

[enia ami]

Posted on February 21, 2017 at 16:39

Well...tried lot of things again...without success.

Then I checked the HW on the microscope...It appears that there is a f**king very tiny cut on one track. It was impossible to measur beacause of the very thin portection film on the TS chip...

Trying to fix it and I ordered another screen.

Anyway thanks a lot for the help