EmbeddedRelated.com
Forums

Writing to registers of IQS620A sensor.

Started by baranov 2 months ago19 replieslatest reply 1 month ago94 views

Hello all.

I am trying to write bytes to the registers of IC IQS620A but as I read them back, I read factory default values all the time. Do I have to do something in order to enable writing?

As I receive quite specific data rather then random values, I conclude that i2c communication works.

Thanks,

Aleks.

[ - ]
Reply by matthewbarrJune 6, 2024

From the IQS620A data sheet revision 3.00, section 7.4, page 34:


Please note:

1. Stop-bit disable and enable must be performed at the beginning and end of a communication window. The first and last I2C register to be written to ensure no unwanted communication window termination.

2. Leaving the Stop-bit disabled will result in successful reading of registers but will not execute any commands written over I2C in a communication window being terminated after an RDY timeout and with no IQS recognised stop command.


I don't have any experience with this device but perhaps this explains the write problem, and stop-bit enable will get you past it.

I'm a big fan of a scope with serial decode capability to debug these kinds of problems, you can see exactly what is going on including possible SI issues.

Good luck!

[ - ]
Reply by Ted2023June 6, 2024

Matthew, What scope are you using for serial decode? About a year ago I bought a Siglent SDS 1104X-E specifically to do serial decode. Beautiful scope, but none of the serial decode options work properly. Only sporadically captures 10% of the signal. And I did return it for another one, which has the same problem. Ted 

[ - ]
Reply by skstrobelJune 6, 2024

It is quite possible to decode I2C by hand.  If you can't directly capture and print a screenshot, take a picture of the scope screen and print that.  It takes a while to do, but it isn't very hard.  You can find the I2C spec online (e.g. https://www.nxp.com/docs/en/user-guide/UM10204.pdf), but the datasheet for the part you are using might have enough info without digging through the whole spec.

You could also use something like a Bus Pirate to decode I2C (I have one but haven't tried it yet), or a USB logic analyzer (I have one but have used it only a little bit).  https://www.amazon.com/gp/product/B07KW445DJ/ref=p... is only $12 and works with the free PulseView/Sigrok software, which will do I2C decode.  Naturally a logic analyzer won't show some of the issues that a scope would reveal, but if all of your pulses look nice and square on a scope, it should do the job.

[ - ]
Reply by baranovJune 6, 2024

Hello, Steve.

I saw valid I2C frames on the scope and on the Beagle I2C analyzer. Besides, I can read the registers, which IMHO would have been impossible if I sent wrong address at first.

Thanks!

[ - ]
Reply by DilbertoJune 6, 2024

I have been using an analyzer like the one of the Amazon you showed for debugging I2C interfaces for at least 3 years, and it works nicely.

It's straightforward to configure, triggers reliably and shows information at a high level.

[ - ]
Reply by Ted2023June 7, 2024

Thanks, two tools I have used that work pretty well are the Kingst Electronics LA1010 logic analyzer, and the Tibbo IO Ninja I2C/SPI Tap.

[ - ]
Reply by matthewbarrJune 6, 2024

I have a Picoscope 3205D MSO (100 MHz) and a Rigol DS1054Z (50 MHz) at home. I've used them for UART, SPI, I2C, SMBus and CAN with good results.

Pico Technology makes great equipment and has gotten increasingly proud of their offerings over the years! The DS1054Z is still very reasonably priced.

[ - ]
Reply by Ted2023June 6, 2024

Thanks

[ - ]
Reply by baranovJune 6, 2024

Well, thank you!

But as far as I could understand the datasheet, this feature is reserved for master devices, which are not fully i2c standard compatible and can generate stop in a wrong moment. So using this STOP DISABLE they protect the communication frames.

Yes, I have Tektronix MSO2014B with bus interpretation feature.

Thanks again!

[ - ]
Reply by matthewbarrJune 6, 2024

Understood, and if it's not in the stop disable state then writes should work. It looks like the I2C settings register (0xDA) should tell you what state it is in, and it should be enabled by default.

I hate problems like this!

[ - ]
Reply by tcfkatJune 7, 2024

Hello!

1) Which registers are concerned? Registers 0x00...0x2B are read-only, writing to them makes no sense.

2) Did you follow exactly the read/write procedures as shown in the datasheet?

screenshot_iqs620a_3427.png

[ - ]
Reply by baranovJune 7, 2024

Hello and thank you for discussing it with me.

I want to write 0x77 to register 0x46:

My writing transactions are:

0,1,0:06.812.354,206.600 us,1 B,,SP,44,Write Transaction,46

0,2,0:06.832.398,205.700 us,1 B,,SP,44,Write Transaction,77

Here is what I see on my analyzer as I try to read from 0x46:

0,1,0:19.311.574,207.200 us,1 B,,SP,44,Write Transaction,46

0,2,0:19.311.794,580.600 us,1 B,,SP,44,Read Transaction,D0*

0xD0 is not a random value but exactly the factory default value of register 0x46.

Besides, I can read register 0 with the product number and it is 0x41 (0x4 = D’65: IQS620(A) product number (all versions))

0,3,0:19.312.613,290.300 us,1 B,,SP,44,Write Transaction,00

0,4,0:19.312.920,591.000 us,1 B,,SP,44,Read Transaction,41*

 It makes me think that I have problems with writing. Or maybe there are certain conditions at which the device accepts the data. I tried to play with the "READY" signal, writing, when READY sets to 1 or 0 but did not have a success.

PS I could not insert screenshots here, so I pasted CSV exported lines.

[ - ]
Reply by tcfkatJune 7, 2024
Once again, are you sure that you are following the writing routine meticulously?


Edit, imho you must:

- Master sends start condition

- Master sends I²C device address 0x44 plus Write command (R/W bit LOW)

- Slave sends ACK

- Master sends register address 0x46

- Slave sends ACK

- Master sends register value 0x77

- Slave sends ACK

- Master sends stop condition


This has to be done in one transfer, no stop condition in between!

[ - ]
Reply by baranovJune 7, 2024

I think, I am.

[ - ]
Reply by tcfkatJune 7, 2024

Did you see my edit?

[ - ]
Reply by baranovJune 7, 2024

Oh, I did not. Thanks! I will check that.

[ - ]
Reply by baranovJune 7, 2024

Yes! You were right. I removed STOPS between address and data and that was the point.

Thanks, tcfkat! Thanks, everybody!

[ - ]
Reply by tcfkatJune 7, 2024

Fine! So, a typical RTFM-problem ... ;)

Get familiar with I²C-protocol, you will encounter this more often.

[ - ]
Reply by tcfkatJune 7, 2024

From UM10204:

"Updated the terms 'master/slave' to 'controller/target' throughout to align with MIPI I3C specification and NXP's Inclusive Language Project"

Sorry, I missed that one and sorry for my non-inclusive language ... ;)