Reprogramming "old" Sennheiser Microphone - Part 3 - EEPROM

 EEPROM 

 So, I was able to connect to I2C on the board, see the communication and understand it, little bit. Now the question is, If I'm also able to read the EEPROM without removing it from PCB. Chip is quite small and de/soldering would be painful. Every time you desolder SMT component there is quite high risk that you might remove also the layer of copper which results in destruction of PCB, or in the best case, painful repair.

 For the communication the easiest way is to use Arduino board and I2C library, since I have on hand ESP32 I will use this one with Arduino IDE which makes it simple. Thanks to internet there is already a guy who was playing with this particular EEPROM and Arduino, so it makes the effort even easier. Simple Copy-Paste with some modifications to read position 0x10 since I know what is stored there from the I2C communication.

 For physical connection I used logic analyzer probes just connected them to the ESP32. Uploaded the program, turn on the mic and waited for while to be sure there is not any communication on the bus. Since I'm using another "illegal" Master on the bus I have to wait for silence in order not to get into some conflict. There is actually one really nice article about I2C that shows some of the most basic stuff about the protocol. After triggering the read, I received on serial monitor value that is correct!

 After this proof of concept I can simply expand the program to read all EEPROM and print each address on serial plotter! Formatted as HEX address and HEX data separated by "-".

...

34-FF

35-FF

36-FF

37-FF

38-FF

39-FF

3A-FF

3B-FF

3C-FF

3D-FF

3E-FF

3F-FF

40-79

41-83

42-0

43-79

44-87

45-0

46-79

47-92

48-50

...

 From serial plotter to txt and then processed by simple Python script to make it easier to read and play around. Would be even better and more proper to convert it into bin file, but I don't have much experience working with it, so formatted txt is ok for me.  Each row is 12 bytes. Already started to split and join the frequency numbers to make it more readable for me.

00ffffffffffffff

ffffffffffffffff

1000ffff00ffffff

ffffffffffffffff

534b4d333037322d

5500000000000000

ffffffffffffffff

ffffffffffffffff

798300

798700

799250

801775

802875

804150

805600

800950

814300

...

Looking at the data the main layout looks like this.

0x50 > 0x40-0x9F = 32 Channel freq.

0x50 > 0xA0-0xBF = 32 Channel Number+1

0x51 > 0x40-0x9F = Channel ???

 Channel frequency is saved in fake DEC format meaning that 0x80 == 80. That's the number used to feed the display. Then there are channel numbers which are user defined numbers for each channel this is HEX+1. 

 All of this doesn't seem complicated. But, in the second part 0x51 in memory there is block that has the same size as channel frequencies in the first block and for each frequency there are three hex numbers. After some playing around with excel I found out that there is some connection between these numbers and frequencies. But I was not able to find any clear formula to understand the relation.

 This kind of approach of blindly trying to find some solution is definitely not the right way to solve stuff. It reminds me of my kids when the zipper gets stuck and they keep on pushing it. The right way is to stop and focus on what is the problem, understand it and finally come up with the right solution.

So after looking back at the I2C communication it's actually clearly visible that when the frequency is changed CPU reads these three values from the second block right before it starts communication with PLL. So these values has to be some kind of settings for PLL. And that clearly means that if I want to write new frequency to the memory I have to understand how to calculate these numbers for each of it.

 Hey, Ho, deep down the rabbit hole.

More in part 4