I2C receiving invalid byte from the FIFO register

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I am working on I2C connection in PSoC4 between MAX30105 particle sensor and PSoC CY8C4247AZI-M485.

   

When I program the code, I get data that is unusable. Almost every entry in console is either 255 or 239 when the output is observed as uint8 noninverted.

   

This program is heavily inspired from another solution, and I do not quite understand the overflow counter or interrupt status does, but if I remove them, I end up in I2C_1_I2CMasterSendStop in line 331.

   

Currently it has both R(Red LED) and IR(InfraRed LED) on, and the ADC is 18 bits.

   

This is my first post, so I'm not quite sure what information I need to add to the post.

0 Likes
5 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Welcome in the forum.

   

Usual I2C issues come from a bad pull up resistor on sda or scl. check that.

   

It will be better for you to put the i2c write sequence into a function which gives fewer places to check for issues.

   

Keep in mind that there is a status byte returned for every I2C call (except reading a byte). Check that for non zero.

   

Configure the I2C component for "Byte mode"

   

Can it be that the sensor requires some time after a reset?

   

Are you using a Cypress kit? Which one??

   

Bob

0 Likes
Anonymous
Not applicable

Thank you for the help. I have configured the I2C component to byte mode, and as far as I can read, the sensor works immediately after the setup is complete, which shouldn't take very long. 

   

The byte mode does not change the output signal in the console.

   

I'm using PSoC CY8C4247AZI-M485, PSoC 4200M or CY8CKIT-043. I use PSoC Creator 4.0. I don't know which of these names you're referring to.

   

In 4200, changing drive mode to resistive pull-up has no effect. How do you check that?

   

You say I should put the write sequence into a function. Can you elaborate on that?

   

Why is checking for non-zero necessary, and should this be after each I2C call or just once? Also, by checking, do you mean to debug and add watchpoints on each of my I2C calls on write?

0 Likes
Anonymous
Not applicable

A WIP update. When I comment out the for loop for NUM_SAMPLE_TO_READ, I get some data that may be more readable.

   

It varies from 0 2 XXX when the sensor is not pressed, to 0 30-32 XXX when the sensor is pressed. Is there something in the for loop that makes errors in the loop itself. As I read it, you need a Start or ReStart before ReadByte, but does it need to be before each call to the function or before each loop of the function.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I'm not sure how to manage to set the drive mode of the buried pins, but I would suggest using P4_0 and P4_1 for SCL and SDA and using the internal pullup resistors of your board.

   

"You say I should put the write sequence into a function. Can you elaborate on that?"
This is the programmer's bread and butter, creating functions as in your case:

   

uint8 WriteOneI2CByte(uint8 DeviceAddress, uint8 RegisterAddress uint8 ByteToWrite);  //returning success or error

   

"Why is checking for non-zero necessary, and should this be after each I2C call or just once?"
At least while testing your project you should verify each result. A failure of one call will prevent the following calls to work correctly. Checking the returned state can prevent your project going into an infinite loop (I2C hasn't got a timeout feature), so better chexk and take fixup).

   

Yes, using the debugger and testing the result of each call will quickly get your project to work.

   

Some hints: Set a breakpoint at the first call. When reached (and result is ok), remove it and set a bp at the next call. Avoid single-stepping because that may conflict with interrupts.

   

And at start of main() insert a CyGlobalIntEnable, this is needed for I2C interface.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

The data is still wonky. I have checked every output for every I2C call except readbytes, and no errors have been found.

   

I have also tested if it was a time reliant error by making infinite loop if(error), and still, the program runs without getting stuck.

   

Some new problems have been encountered. The FIFO_WR_PTR and FIFO_RD_PTR can both exceed their limits of 0-31.

   

 The FIFO_RD_PTR can move without reading any FIFODATA.

   

Also, how do I change my username to my name on the forum?

0 Likes