According to the IQS213 documentation, the ready / TO2 line is supposed to go low after startup to signal that the IQS is ready to receive commands from the controller.
However, this is not happening. The TO2 line is supposed to have a 4.7 kOhm pull-up resistor. Instead I have used the processor's internal 11-16 kOhm resistor as pull-up. Since it's larger than the specified resistor, it should not prevent the line from going low.
I've verified:
- Power (2.8V)
- Ground
- VReg (1.68 V)
- Checked for shorts
- Orientation of chip
Still no ready low.
Next step will be to look for anomaly notes from Azoteq, and program an ACK handshake to see if that could work.
5 comments:
Hi Erl,
Where you ever successful in communicating with the IQS213? I'm currently struggling with it. I'm able to get the RDY pin to go low but get no ACK on the address, trying both 0x44 and 0x88, as it seems the evaluation kit is using 0x88 although the documentation states 0x44.
Any insights?
Thanks,
Daniel
I have not spent much more time on this.
I E-mailed with Azoteq, and got confirmation that there is a typo in the "AZD066 IQS213 Communication Interface Guidelines" that showed a 100kΩ pull-up resistor for RDY, it should be 4.7k - 10k.
About I2C, they said "Did you in fact burn the OTP bit to enable the i2c mode? (the IQS213 is default in a stand-alone output mode, with a 2channel self-capacitive swipe function, so pin 6 will go low if a swipe event occurs between CX0->CX1)". I had been hoping that it would startup in the same debug mode as the evaluation kit, so that I could switch modes at runtime.
My next step is to ask Azoteq how to set get the chip to start in the same mode as the evaluation kid, where the mode can be changed dynamically.
Let me know if you find any more information! It's good to know that I am not totally alone in this!
I swapped the sample chip I had with the chip on the evaluation board. The evaluation board is still working fine so I guess the RDY line handshake can put the chip into I2C mode even if the OTP bits have been programmed. I don't think they are programmed, in any case.
I was using a 10K pullup to start with.
Looking at the bus timing on the evaluation board with a scope I see signals which don't match AZD066, I'm also waiting for help from Azoteq support.
I'm trying to use a STM32F4 chip with its hardware I2C driver. I wonder if the evaluation board, which also has a STM32 processor, uses it, too.
AZD066 lets me believe the protocol might be "bit banged" with special timing.
I will update you if I make any progress.
Thanks!
Hi Erl,
After some correspondence with Azoteq, they strongly recommend switching to the IQS263 chip and I will be doing that. They claim this is a newer chip and supports I2C by default unlike the 213 which supports it for debugging only. Setting it to debug mode is done using the CT210 programmer. The eval kit switches the standalone chip to debug without programming the OTP but they did not explain how in detail only that the configuration bit defining i2c is written. I do see, with the scope, that a actual power reset of about 300 ms is applied to the chip to begin this process. I could not see what data was actually written to enable the bus.
Hi Erl,
Well, according to the recommendation I am using the IQS263. Nothing special to add, the implementation was straight forward, monitoring the RDY which is active on this device. Once the RDY line is low comm. simply works. Please note the slave address used is 7 bit 0x44, meaning the high bit on the address register, at least on my hardware, is 1, leaving the lease significant bit for the read/write. On my machine's addressing conventions this means the address is actually 0x88.
Regards,
Daniel
Post a Comment