We would like to utilize ADC inputs on Colibri i.MX6 modules, which are provided by STMPE811 touch screen controller. As we already found out hard way, there are some limitations which we have to consider in hardware design.
Most important is the fact that Analogue Input<1> on Colibri i.MX6 (pin 6 on SODIMM connector) that is connected to pin 9 of STMPE811 is used during reset to select between I2C and SPI interfaces. That effectively means that we have to take care of that during SoM reset and bootup.
Could someone from Toradex specify if there is any pull-down connected to said pin on the SoM module? I am not able to find this information in Colibri i.MX6 datasheet.
Maybe you could include some kind of big fat warning for the Analogue Input<1> in the datasheet? I am not saying that the current documentation is wrong or missing something, but we think that this kind of vital information should be specified directly in the SoM datasheet.
I also believe that STMPE811 Pin Name in table 5-42 should contain values IN0_GPIO0, IN1_GPIO1, IN2_GPIO2 and IN3_GPIO3 instead of all pin names beginning with IN0_ prefix.
I have retested behavior on Viola carrier board (I have wrongly stated in Environment that we use Viola carrier board in first post, sorry about that), and it seems to be working as expected here.
Premise:
There is something (just transistor, or something smarter?) connected to IN1 (pin 9) of STMPE811 on the SoM. We assume that this pulls the pin LOW during reset in order to set STMPE811 to I2C mode.
Experiment:
I have used SoM on Viola carrier board, and connected ANALOG_IN1 to +3.3V using 47k resistor (same value as used between STMPE811 and pin on SoM module). Using oscilloscope, I am able to measure voltage drop on ANALOG_IN1 to ~1.6V during SoM reset, which is exactly what is expected when IN1 is pulled down to GND (we measure the voltage between two 47k resistors).
Could anyone look into this issue? We will probably settle on keeping this analog input unused as we only need to use 3 analog inputs, but it seems quite strange…
Thank you for the very detailed information. As you have suspected, there is a circuit on the module that pulls down the IN1_GPIO1 pin of the STMPE811. This is required since the input pin is used for strapping the device to use it with an I2C interface. Here the according schematics on the module
Looking at your measurements, I can explain what is happening during the power up sequence of the module. At first, the +V1.375_CORE, as well as the supply rails for the STMPE811 are not up. Therefore, the circuit is not pulling down the signal. As soon as the +V1.375_CORE is available, the circuit is shorting the signal at the input of the codec pin to ground. This remains until the internal reset signal (PWR_CPU_RESET#) is released.
The time between applying the main 3.3V for the module antil the +V1.375_CORE gets available depends whether there is an RTC battery available or not. If there is no battery available, the PMIC needs first to initialize its own RTC until it starts with ramping up the rails.
Thanks for further information. We do not use battery backup for RTC and VCC_BATT is tied to +3V3 rail in same way as it is done on Viola carrier board.
Could you possibly explain why is IN1_GPIO1 pulled down by +V1.375_CORE voltage? We assume that STMPE811 has both V_CC and V_IO connected to +3V3. And since STMPE811 is kept in reset state by PoR tied to V_IO pin, it seems strange to use different rail to keep IN1_GPIO1 tied to ground. But maybe we are just missing something because we do not have complete schematics.
Please apologize the late answer. I was having quite a busy wee since I was at the Embedded World in Nürnberg. The In oder to meet the power up requirements of the i.MX6, the V_CC as well as V_IO voltage rail of the touch controller are not connected directly to the main 3.3V input of the module. There is a switch between the module input voltage an the voltage rail for the touch controller. This means, the STMPE811 is powered up after some other rails (including +V1.375_CORE) are available.
The reason why we need to pull down the IN1_GPIO1 is that this pin is used as strapping for the audio codec. The voltage level of the IN1_GPIO1 is read by the STMPE811 during its own power up. If the level is low, it is in the I2C mode, while a high level sets the chip into SPI mode. Since we need to make sure that the chip is strapped to the I2C mode (we cannot communicate with the STMPE811 when it is in SPI mode), we need to make sure that IN1_GPIO is low during powering up the STMPE811 even if there is a voltage applied to pin 6 of the SODIMM connector.
Since there is a minimum setup time for the input pin, we have to make sure that the pin is set low before the V_IO pin is going high. Using the same rail for pulling the pin low would mean that we are not able to set the pin low fast enough. Therefore, we use the +V1.375_CORE rail which is available before the V_IO is up.
@peter.lischer No need to apologize, I understand that time is limited source. I have visited Embedded World on Tuesday, Toradex booth included
Thanks for explaining how is STMPE811 connected to power rails, I can now understand why are you using +V1.375_CORE rail for strapping the IN1_GPIO1.
Unfortunately that still does not explain why it does not work on our custom carrier board. I am not sure if you have read my comment with oscillograms of power-up sequence on Viola board and our carrier board, but we believe that the difference in power-up sequence is somehow causing the issue. Maybe our power-up is just too fast?
Note: You are talking about STMPE811 as of audio codec, which it is not. I assume you have mixed it up with SGTL5000 that is also used on Colibri module and uses same strapping to switch between I2C and SPI mode.
What do you mean with “it does not work on our custom carrier board”? Is the ADC input not working at all or what exactly is the issue?
I was having a look at your scope pictures and your comment. I just do not understand your concerns. Is it the fact that even before the transistor circuit is pulling down the signals, the input voltage does not reach the full input voltage? If so, the explanation is that the STMPE811 is not powered at the beginning. Since it is not powered, the internal protection diodes are conducting. There is a current flowing from the IN1_GPIO1 pin over the internal protection diode to the supply rail of the STMPE811. This is not an issue since the current is low due to the 47k series resistors. The reason why there is a difference of the measured voltage between your carrier board and our viola is very probably due to a different voltage of the STMPE811 supply rail during boot up. Please understand that the supply rail of the STMPE811 is not completely 0 if the rail is switched off. The rail can have a certain voltage due to back feeding. The actual resulting level depends then on the amount of pins that are back feeding and the load on the rail.
Yes, I mixed up the “audio codec” with “touch controller” in my last post. I always meant the STMPE811 touch controller. Please apologize any confusion.
@peter.lischer I apologize, I have read all my posts again and realized that I have in fact did not clearly described the issue I observe here.
We use Analog Input <1> on Colibri module to measure some voltage, so there is pretty much always some voltage (>2 Volts) on the pin. I have found out that if the voltage is present here during power-up, the Linux can not find the STMPE811 on I2C bus (initialization during boot fails, and i2cdetect does not see the device either), therefore I assume it has been switched to SPI mode during power-up. If there is low voltage on the pin during power-up, everything works as expected.
I have retested this on Viola carrier board, and I am not able to switch STMPE811 to SPI mode by pulling Analog Input <1> pin to +3V3 rail. We suspect that the issue must be related to power-up sequence.
I hope that I have described the problem clearly now. If you need more information, just ask, I will try to provide more details.
Thank you for clarification. As you already found out, the STMPE811 is strapped wrongly to SPI instead of I2C. As I described before, there can be some back feeding on the power supply rail of the STMPE811 (+V3.3 rail). This is not an issue as long as the voltage does not reach the power on reset level of the STMPE811 before the +V1.375_CORE rail is able to pull down the IN1_GPIO1 signal.
On your module, very probably the back feeding on the +V3.3 rail is is very high which means the STMPE811 goes comes out of reset before the power sequence has actually switched on the +V3.3 rail.
In order to confirm that, could you please measure the +V3.3 rail during power up sequence an compare it with the viola board? You find the location of the test points here.
If you are facing a back feeding issue, we need to figure out what can be done to reduce it. Normally the back feeding is caused by I/O pins that are driven high by the carrier board while the module is not powered up. This is not completely avoidable but you might be able to reduce the number of pins.
