search

kriswiner / EM7180_SENtral_sensor_hub

(Affordable) Ultimate Sensor Fusion Solution
https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution/
96 stars 37 forks source link

Method of Reading Consistently from EEPROM #48

Closed othnielosaur closed 5 years ago

othnielosaur commented 5 years ago

Hi I'm trying to write a circuitpython calibration file for the USFS MPU9250. When accessing page 255 of the EEPROM you use :

Part 2: Were there difficulties reading data from the M24512? - the data it is providing me starts at inconsistent points in the EEPROM each time I try to read - any tips?

https://github.com/kriswiner/EM7180_SENtral_sensor_hub/blob/0918573f04473b36da015bc28e4f18a734753a58/WarmStartandAccelCal/EM71280_MPU9250_BMP280_M24512DFC_WS_Acc_Cal.ino#L1111

kriswiner commented 5 years ago

The EEPROM address is not pages and not bytes but bits. 2^16 bits = 65536 bits = 512, 128-byte pages. Each bit has its own address...

On Tue, Jan 29, 2019 at 3:07 AM othnielosaur notifications@github.com wrote:

Hi I'm trying to write a circuitpython calibration file for the USFS MPU9250. When accessing page 255 of the EEPROM you use :

  • M24512DFMreadBytes(M24512DFM_DATA_ADDRESS, 0x7f, 0x80, 12, &data[128]); // Page 255
  • For context see link below Part 1: Why do you write in two subaddresses 0x7f & 0x80 -> see function M24512DFMreadBytes? I've worked out that 0x7f | 0x80 = 255 but why would you not just write in 0xFF to get to page 255 - I've searched through the M24512D manual, but I'm not exactly sure what I'm looking for. Your comments are easy to follow thanks :-) but just this line and its underlying function has baffled me.

Part 2: Were there difficulties reading data from the M24512? - the data it is providing me starts at inconsistent points in the EEPROM each time I try to read - any tips?

https://github.com/kriswiner/EM7180_SENtral_sensor_hub/blob/0918573f04473b36da015bc28e4f18a734753a58/WarmStartandAccelCal/EM71280_MPU9250_BMP280_M24512DFC_WS_Acc_Cal.ino#L1111

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/48, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qpcNVtFeEargDeuiYkD81MqqH9k2ks5vICtqgaJpZM4aXz4i .

othnielosaur commented 5 years ago

So why have you specifically addressed the location [0x7f, 0x80] - is that arbitrary as long as the location is consistently referenced - i.e. line 1134 & line 1111?

Other symptoms: I can't seem to get reliable data out of [0x0N, 0xPQ] where N is an odd number - it just spits out \xff\xff\xff.... Only get interesting data out when N is even. PQ = arbitrary.

Also I don't get the correct response from line 376 instead I get 0x00 & 0xA6 from data[0] & data[1] respectively

Tried a couple of different ways of implementing i2c that circuitpython provides - no different results there. I'm definitely able to see the i2c address of the EEPROM and get data out of it, it's just not the data I think I should be seeing based on last observation above.

Any other pointers? TIA

kriswiner commented 5 years ago

EEPROM data sheet? This isn't rocket science..should be easy to use an EEPROM.

On Fri, Feb 22, 2019 at 4:44 PM othnielosaur notifications@github.com wrote:

So why have you specifically addressed the location [0x7f, 0x80] - is that arbitrary as long as the location is consistently referenced - i.e. line 1134 https://github.com/kriswiner/EM7180_SENtral_sensor_hub/blob/0918573f04473b36da015bc28e4f18a734753a58/WarmStartandAccelCal/EM71280_MPU9250_BMP280_M24512DFC_WS_Acc_Cal.ino#L1134 & line 1111 https://github.com/kriswiner/EM7180_SENtral_sensor_hub/blob/0918573f04473b36da015bc28e4f18a734753a58/WarmStartandAccelCal/EM71280_MPU9250_BMP280_M24512DFC_WS_Acc_Cal.ino#L1111 ?

Other symptoms: I can't seem to get any data out of 0x0N where N is an odd number Only get data out when N is even.

Also I don't get the correct response from line 376 https://github.com/kriswiner/EM7180_SENtral_sensor_hub/blob/0918573f04473b36da015bc28e4f18a734753a58/WarmStartandAccelCal/EM71280_MPU9250_BMP280_M24512DFC_WS_Acc_Cal.ino#L376 instead I get 0x00 & 0xA6 from data[0] & data[1] respectively

Tried a couple of different ways of implementing i2c that circuitpython provides - no different results there. I'm definitely able to see the i2c address of the EEPROM and get data out of it, it's just not the data I think I should be seeing based on last observation above.

Any other pointers? TIA

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kriswiner/EM7180_SENtral_sensor_hub/issues/48#issuecomment-466596464, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qjkXspRpgfwngxKsJjmnUeU1mprKks5vQI7QgaJpZM4aXz4i .

gregtomasch commented 5 years ago

Here's the rules for addressing the M24512-DF: 1) The memory is SEGMENTED into 512 pages 2) Each page contains 128bytes 3) To address any arbitrary byte, first specify the page number (0-511) 4) Then specify the byte number (0-127) 5) This is why there are two "Register address" bytes sent in the I2C transaction... 6) HERE'S THE BIG ONE: If you are reading or writing multiple bytes, you can only increment the byte number WITHIN THE CURRENT PAGE 7) For example, say you want to write 129 bytes starting on page 0x00 starting at byte number 0x00. You write bytes 0-127; no problem... What happens when you byte 128? Doesn't it increment to page 0x01 and byte number 0x00? NO IT DOESN'T! It overwrites byte number 0 with the data in byte 128! 8) So you can only write 128 bytes in a single page. In the example above, the I2C transaction would have to be ended when the 128th byte was written. To write the 129th byte, you would have to open a second I2C transaction on page 0x01 and write the 129th byte into byte number 0x00...

So: 1) This memory is segmented into pages and byte numbers; you have to transmit both addresses in the beginning of the I2C transaction. 2) You can only auto-increment the byte number to the end of the 128-byte page. 3) So stop when you hit the page boundary, close out the I2C transaction and start a new I2C transaction on the next page...

Finally: "So why have you specifically addressed the location [0x7f, 0x80] - is that arbitrary as long as the location is consistently referenced - i.e. [line 1134] and [line 1111]?"

This page/byte is referenced because it is beyond the end of the largest allowable Sentral FW image... We start at this page/byte address to guarantee we that do not corrupt the FW...