ZMOD4410 - I2C with MSP430FR2155

Thread Starter

Rui Fernandes

Joined Mar 25, 2021
5
Hi,

I am currently working with a sensor platform to measure IAQ. One of the sensors that I am using is the ZMOD4410 developed by Renesas to measure TVOC. I am having trouble with the sensor's I2C. In the datasheet it says that the implemented transmission protocol is similar to conventional EEPROMs, which I am not very familiar. I also have the firmware provided by the company's sensor and I have developed I2C functions to write and read but I still have problems and I think, when it all comes down, it is because of the way that I am reading and writing values from/to the sensor.

I am here to ask for tips/explanation about the transmission protocol, if someone has any experience with conventional EEPROMs. Also, if someone had/is having any problems with the ZMOD's I2C share your experience maybe you could help or we could help each other.
 

mckenney

Joined Nov 10, 2018
125
What symptom are you seeing exactly?

The two most common goofs I see with I2C are (1) forgetting the bus pullups (2) using an 8-bit (SLA byte) value for the slave address (your code should say "UCBxI2CSA=0x32;").

The "EEPROM" reference isn't wrong but it's a bit of a red-herring. It follows a fairly standard register read/write model, (8-bit register numbers) with auto-increment.

What platform are you using? I don't know of any off-the-shelf breakout boards for the FR2155 specifically, so I'm guessing it's a custom board.

There is a collection of FR2155 examples at the TI site, 6 of which apply to I2C:
https://dev.ti.com/tirex/explore/node?node=AOnF7fIgXVB02jcaruRWng__IOGqZri__LATEST
 

Thread Starter

Rui Fernandes

Joined Mar 25, 2021
5
mckenney thanks for the reply.

It is a custom board. I do have the bus pullups and I have other sensors in that bus with different slaves and they are all working, so the pullups might not be a problem. The slave address is correct, because I can do some commands, particularly I think when I try to read it is correct, because when I ask the ZMOD for the product ID, it gives me back the correct one.

The main problem is when I am trying to write a configuration to a certain address, in this case 0x60, I want to send 2 bytes to data and in the second one byte a get a NAK from the sensor, which leads me to believe that that particular byte was not received by the ZMOD.

One question, have you ever worked with this sensor and did you had access to their firmware?
 

mckenney

Joined Nov 10, 2018
125
I haven't worked with this sensor before, but I've worked with a number of I2C sensors. The User Guide and (I think) the sample code is behind a registration wall, so I haven't seen them.

There is a note in the data sheet (Sec 11, 2nd-3rd paragraphs) which suggests that in general you're not supposed to Write to the registers; I don't know if this means Read Only (possible cause for NACK). It does suggest you can write/read-back registers 0x88-8B; have you tried that?
 

Thread Starter

Rui Fernandes

Joined Mar 25, 2021
5
Yes I have and I have a lot of examples.

1. Send data = [0x88, 0x01] Only ACKs and I can read the data when I access 0x88, but I also receive a 0x00 NAK, maybe because I am only trying to read one byte.

2. Send data = [0x88, 0x01, 0x02], I get ACK on 0x01 and NAK on 0x02 and I read the same as example 1

3. Send data = [0x88, 0x89, 0x01], I get ACK and I can read 0x89 and 0x01

4. Send data = [0x88, 0x89, 0x01, 0x02], I get all ACKs except 0x02 and I read 0x89 and 0x01

5. Send data = [0x88, 0x01, 0x89, 0x02], again ACKs in all except 0x02 and I read 0x01 and 0x89
 

mckenney

Joined Nov 10, 2018
125
Hm. I don't see an obvious pattern, except that it NACKs a 0x02 byte (or maybe any even-numbered byte?), which would be a very unusual symptom. Do you by chance have a scope trace?

Here's a shot in the dark: Do you know how fast you're running the bus? As in: If you divide SMCLK by BRW, what speed do you get? In many cases BRW is very small, so it's easy for rounding error to push the speed over 400kHz. Most devices are fairly forgiving here, but each I2C device seems to have its own quirks.

[I went ahead and registered at Renesas, but then to get any of the (4x) firmware packages I need a salesperson name, which I don't have since, well, I'm not a customer. The EVK code appears to be all PC-side.]
 

Thread Starter

Rui Fernandes

Joined Mar 25, 2021
5
I have scope traces from a Logic Analyzer, not sure if that helps, but I'll put them here.

Right now, I'm having a different behavior when I try to send two or more bytes and try reading them after, the SDA only gives 0x00 followed by ACKs and it goes down, never coming back up. At first I thought it was the clock low timeout, but the interrupt flag is not getting set, so I forgot about that approach.

In terms of the bus speed, I have the SMCLK at 16 MHz and the BRW, which I'm assuming is the data rate is at 100 KBPS and I don't think this micro supports any higher than that. So that gives a speed of 16MHz/100KBPS = 160kHz. What's your opinion on this, if I am doing correctly?
 

Attachments

mckenney

Joined Nov 10, 2018
125
If BRW=100 and SMCLK=16MHz, then the bus speed is 16MHz/100=160kHz. Both sides claim to be capable of this.

The UCCLTO timeout applies to the clock (SCL). Having SDA sit low like that is a bit unusual (typically you'll see a little up-tick during the data/ack handover) but it's not illegal. In that example the master (your code) is in control, and can stop when it chooses, so the SDA-low won't go on forever. I imagine it shows up as 0x00 since you haven't yet succeeded in writing at 0x89.

Having the second write byte get NACK-ed still seems odd, since they explicitly say (1) you can write multiple bytes and (2) you can write whatever you want into 0x88-0x8B. It seems like there's some other rule I'm not seeing.
 

Thread Starter

Rui Fernandes

Joined Mar 25, 2021
5
That's also what I am thinking, that there is some other rule that's not being explicitly said. What I am thinking is that it has something to do with the address pointer. Because it says in the datasheet: "This address pointer must be set during an I2C operation", do you have any thoughts/hints on that?
 

mckenney

Joined Nov 10, 2018
125
"This address pointer must be set during an I2C operation"
"This address pointer must be set during an I2C write operation." This is quite standard since there's no way to write the register number during a Read operation. I.e., you Write a piece of state (the register index) into the device, then the next Read reads from there.

Besides some sort of data dependence (which data sheet Sec 11 insists isn't the case, but maybe try writing 0x08 or 0xFF) the only other thing I can think of is that maybe the bus signal isn't quite as tidy as the analyzer claims. One thing to try is to slow the bus way down -- 50kHz, or even 10kHz -- since a slow bus is usually more forgiving of signal anomalies. If that improves things that tells you something.
 
Top