Another thing to add, is that my sensor with address 0x51h works and 0x28h wont work.
I spotted that the eeprom is working over the i2c bus and is address 0x50h.
Could my sensor with address 0x28h be interfering with the eeprom and on power up when the system reads the eeprom it causes the program to freeze or become corrupt?
I am not addressing my sensors at any point during the software, so i believe the sensor with address 0x21h is interfering with the reading/writing of the epprom on start up.
I thought that the EEPROM slave address was always set to 0xA0/0xA1?
WICED Sense uses I2C and contains a handful of sensors on the I2C bus. Have you looked at the source for it and tried those slave addresses?
Yes, 0x50h left shifted one place adding a 0 for read and 1 for right will give you 0xa0 and 0xa1.
No not yet, I will have a look and update you but I will confident it is the address of my second sensor (0x21h) that is causing the problem.
Just another thought:
I have software running controlling a sensor over spiffy2 (8 segment display). When my code starts up and passes the initialization my 8 segment displays the number 5. In my software I am doing no reads or writes over the I2C bus to my two sensors on the I2C bus.
On start up the eeprom is be read/write to over the I2C. This is the only communication taking place on the I2C bus.
When I add my sensor with address 0x51h to the i2c bus it passes the initialization and turns on 5 on my 8 segment.
When I add the second sensor with address 0x21h it does not pass the initialization point and the 5 does not get displayed on my segment.
I do not think its a hardware thing ad is I add two sensors with the address 0x51h to my i2c bus (I am not writing/reading to this sensor so there will be no problems causing by having the address for two sensors on the i2c bus) it powers up fine.
This leads me to believe it is been causing by the address of my second sensor 0x21h (not the presents of a second sensor on the i2c bus containing any address) . I feel when the initialization takes place the sensor with the address 0x21h is causing a problem, been read or write by accident causing a failure and this is why it never gets passed this point.
In your first comment you say the address of the second i2c sensor is 0x28, in later posts you say 0x21. Can you clarify this?
How does the system respond when all you do is add the second sensor without having the first on there? If it still malfunctions we steer away from a pf loading issue.
In the event the system still malfunctions can you post the part number of the second sensor? Also, where does the interrupt of the malfunction sensor go?
Can you measure voltage on the 2.8v bus with the bad sensor in place? Can you measure the voltages on your data line with and without the faulty sensor in place? Compare these and see if boot-up is being inhibited by the voltage.
Have you tested with multiple of these sensors or do you just have one?
Sorry if I mentioned 0x21h I actually meant 0x28h.
When I connect the sensor with address 0x28h (the one causing the problem) on its only I still have the same problem.
I would agree I don't think it is a loading issue as when I put two of the good sensor 0x51h on the board it causes no problem (I do not write to this sensor, so there wont be a conflict of addresses).
The pressure sensor at fault is :MS4525DO-SS3AI015VPM. The interrupt pin is going to either P8 or P4 of the BCM20737S. I have disconnected the interrupt pin of each sensor and the problem is still there.
I have two of the good (0x51h) and two of the bad (0x28h) and both of the bad sensors have the same problem.
There is 2.79v at SDA with and without the faulty sensor.
When using a multimeter I could see when I started the program the voltage dropped from 2.79v down to 1v and then back up to 2.79. I scoped this line and there is data been transferred on the i2c sda (presumably) from the eeprom on power up.
The voltage dip I expect when data is traveling on the SDA line. The drop in voltage is likely the DMM's averaging of the voltage on the rail between high and low states.
What I'm highly suspicious of is the fact that the 0x28 address is the address of our EEPROM shifted by 2 bits. It's not likeyl, but if the sensor tries to respond to the 37's EEPROM reads, this contention will inhibit boot-up.
Perhaps disconnect only the SDA line from the sensor, leaving all other pins connected, and ensure that it boots up. If it boots up, and we know that the voltage on the bus is good, we can assume that the sensor is causing data contention.
Looking at the datasheet, I see that the same manufacturer makes a sensor with the same address (0x51) as the good sensor. Is this the one you're using?
The dips on the SDA is the mcu reading from the eeprom on start up I presume.
Yes I agree it is very close.. may be having some interference.
I have done what you mentioned. If leave all pins connected with the sensor (0x28) it fails. If I disconnect either of the sda or scl or both it will boot up. When I put two of the sensors with the address 0x51 on the i2c there is no problem. This what makes me think it is not a loading problem, but a address problem.
Yes I am using the sensor with the address 0x51h which works fine. They have a couple of different address for i2c. Might be worth get a different address besides 0x28 and 0x51 to see if it helps. My biggest problem is that it takes weeks to get a sample, something I don't have right now.
The most definitive solution will be installing the sensor made by the same manufacturer with an alternate address.
In the short term, however, if you have the ability to rework the board, you bring the 0x21 sensor out on its own two GPIO and bit bang an i2c protocol. Since it's a pressure sensor I presume you don't need very fast reads.
Secondly, you can delay the bootup of the bad pressure sensor just long enough for the chip to boot. This can be done by installing a switch between the sensor and the chip on the i2c lines, toggled by a GPIO after application startup. A switch on the power supply will also work.
I am polling data at 1.666khz so bit banging is out of the question I feel.
I have my sensor plugged on a socket. I suppose to test this theory, I could plug out my pressure sensor, boot up the board, once the chip is booted up, plug back in my pressure sensor then take a reading of the pressure sensor to see if I am getting back valid data. If this works its the pressure sensor causing and interference when the epprom reads.
Yes using something like a transistor to toggle the power to the pressure sensor is an idea, but its not a full solutions. It may be a possibility.