kriswiner/EM7180_SENtral_sensor_hub

USFS EEPROM CRC incorrect

Closed this issue · 15 comments

Hi @kriswiner,

I have recently received USFS (SENtral, MPU9250, BMP280) from Tindie.
I am using Teensy 3.5.

I am running EM7180_MPU9250_BMP280.ino modified for my connections (I2C on pins 18/19).

This is the result I get:

Scanning...
I2C device found at address 0x28  !
done

EM7180 ROM Version: 0xE69
Should be: 0xE609
EM7180 RAM Version: 0x00
EM7180 ProductID: 0x80 Should be: 0x80
EM7180 RevisionID: 0x2 Should be: 0x02
A barometer is installed
A humidity sensor is installed
A temperature sensor is installed
A custom sensor is installed
A second custom sensor is installed
A third custom sensor is installed
EEPROM detected on the sensor bus!
EEPROM uploaded config file!
EEPROM CRC incorrect!
EM7180 in initialized state!
No EEPROM detected!
Beginning Parameter Adjustments

Two things are suspicious:

  • all the sensors installed (baro, temp, humid + 3 custom)
  • EEPROM CRC incorrect (probably the cause for problem?)

Could you provide me the firmware that USFS should come with?

Kind regards

Hmm, inspecting the output it looks to me as communication problem, not CRC failure.

  • all feature flags enabled suggest 255 byte in feature flags
  • the sequence for EEPROM suggests 255 in status

It hangs in loop and I verified that param_xfer is 255 (0xFF) constantly

while(!(param_xfer==0x4A)) {
    param_xfer = readByte(EM7180_ADDRESS, EM7180_ParamAcknowledge);
  }

Maybe I messed pullups or something. Investigating.

Any ideas welcome.

I am not entirely sure. After removing the two first 1000 ms delays I get:

Scanning...
I2C device found at address 0x28  !
done

EM7180 ROM Version: 0xE69
Should be: 0xE609
EM7180 RAM Version: 0x00
EM7180 ProductID: 0x80 Should be: 0x80
EM7180 RevisionID: 0x2 Should be: 0x02
0 //this is featureFlag
1 //this is status
EEPROM detected on the sensor bus!
EEPROM upload successful!
Beginning Parameter Adjustments
// this is after delay
//getting 255 forever

So it seems as any delay I do messes the communication. Probably my fault somewhere.

Should the 4.7 k pullup resistors be installed on SCL and SDA lines?
(this is what I did)

You can check, run an I2C scan using the SDA_M/SCL_M (master bus) and see if you can detect the EEPROM (0x50 & 0x58) as well as the MPU9250 (0x68) and BMP280 (0x77). Let me know what the result is.

This is what I got but results are not consistent (suggesting communication problem)
In other words, I get different results on different runs.

Scanning...
I2C device found at address 0x50  !
I2C device found at address 0x58  !
I2C device found at address 0x76  !
done

I will investigate with communication layer.

MCU Teensy 3.5 (mentioned in first post)

Yes, I am investigating.

Are you using i2c_t3?

Yes

Now I also tried with plain Wire with the same result.

Commenting out some more delays it gets further until I2C communication breaks and I keep getting 0xFF for every byte.

Anyway, thanks for any help, I will investigate the communication layer.

Can you use I2C with the Teensy 3.5 with any I2C sensor?

No idea ;-)

I am new to Teensy. I have some I2C devices that I use with Linux.

Preparing connectors would take some time so I will resort to trying simpler methods first.

Anyway, thanks for good suggestion.

Ok!

After re-soldering and rewiring everything I got it working.

One thing to note:

  • the read/write functions in the example don't check for errors (e.g. error=Wire.getError();)
  • if error happens the example may go into somewhat undefined state

I was getting error recv addr NACK which led the example astray.

Apart from working the device now also returns RAM version correctly (non 0).

Works like a charm!

Thanks for help ;-)