kriswiner/EM7180_SENtral_sensor_hub

Method of Reading Consistently from EEPROM

Closed this issue · 4 comments

othnielosaur commented

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?

EM7180_SENtral_sensor_hub/WarmStartandAccelCal/EM71280_MPU9250_BMP280_M24512DFC_WS_Acc_Cal.ino

Line 1111 in 0918573

M24512DFMreadBytes(M24512DFM_DATA_ADDRESS, 0x7f, 0x80, 12, &data[128]); // Page 255

kriswiner commented
othnielosaur commented

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
gregtomasch commented

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...