Reprogramming "old" Sennheiser Microphone - Part 5 - Writing to Memory and Testing

 Writing and testing

 I have table with the values that should be written to into the EEPROM which needed some splitting and padding in order to get it into correct format. Then I added addresses on which data should be written. In this case it should be first 16 channels, that all I need even if there is possible to store up to 32, but the 820-830MHz bandwidth is too narrow for more than 16 channels.

 Transformed the addresses and values to array string, odd is address even is value. But I wanted to start with just one value in order to do make any mistake and test if everything is working so I prepared program to write data to first and second bank. Plug the ESP32 on the I2C bus and wait until there is no communication. Push the button, then after removing the ESP32 turn off and on the mic. Which should not be necessary. Set the first channel that I wanted to overwrite and it show this new, correct frequency! But when tuning the receiver to see if everything is working I did not get any signal... So are my PLL calculations wrong or what? But on the other side if there would be some deep issue with PLL settings, microphone would show that the PLL was not successfully locked. 

 I needed to se what is going on in RF, and luckily I have Software Defined Radio, that means I can scan the frequency range and see if there is some transmission or not. And surely after staring the SDR console I can see that the microphone is transmitting, but on the old frequency. That's actually relief, since it means that everything is fine, just the second block of memory was not overwritten. That also actually explains what I was wondering about before. There is WP pin of memory connected to the programming connector. That means in case programming connector is plugged, this pin gets shorted to ground so new frequencies can be programmed. Also again captain RTFM (Read The F* Manual) to the rescue. And truly its is like this. There are bits on the end of second block of memory that sets from which address its protected. On this memory it is set to whole second block. I was also able to improve my understating of memory layout little bit.

0x50 > 10 = Selected Channel

0x50 > 40-9F = Channel freq.

0x50 > A0-BF = Channel Number+1

0x51 > 40-9F = Channel A and N counter

0x51 > B0-B2 = lower BW limit

0x51 > B4-B6 = upper BW limit

0x51 > FF = write protection for whole 2nd block

0x50 > 11 = gain

 With simple jumper connecting this pin to ground I should be able to unblock writing to second block. With this installed I tried this procedure once more. And after all I got transmission at new frequency! So not only in theory but even practically everything works fine. Now it was all just about expanding program to write 16 channels at once. And as final touch I also changed channel number to be simply from 1-16, since before it was somehow messy.

Conclusion

 This project was really fun as it was not only good for learning stuff, but after all, it was useful. As the last step I put my offer for reprogramming such microphones on eBay for half of what is asking the guy. As kind of retaliation for not accepting my offer and being greedy. 

 There are some lessons for me, which is more like addressing my weak spots. I should study documentation in more details and be more prepared before just playing around. 

There were phases where I was worried about going on with the project and pushing it back since I was not confident enough if it gonna be successful. But as there is already happy ending everything now looks simple and straightforward. And that's the issue of the most of projects. If you are working on something you never now if it gonna have happy ending at all, and for me it's really hard to push forward the motivation. 

 Im borrowing great list of lessons from great article from great person, in case you did not know. 

Lessons for aspiring reverse engineers

• Spend a few hours/days reading before you start doing.

• Prior knowledge helps. You'll get better at reverse engineering as you do it more.

• Code shape is recognizable. SPI drivers all look the same, I2C drivers all look similar, circular buffers all look the same. Code shape is a great hint about code function.

• Assume people who wrote the code and designed the chip are sane (until proven otherwise).

• Newton's first law of software and hardware design: without a significant outside force, things will keep being designed as they always have been. Assume most designs are similar, and what you saw before is likely what you'll see again

• Defaults are not changed most of the time.

• Every bit of knowledge helps eliminate possibilities in other places. When something confuses you, leave it alone and go analyze something else. Come back to this one later when you know more.

• Weird-looking constants mean things. The weirder the number, the more meaning it probably carries

• Have a theory before you rush to try things. An experiment with no theory is meaningless.

• Do try things. A theory with no experiment is pointless.

• Take notes as you try/figure out things, since your "trying things" binary will quickly become an unmanageable mess and you'll forget things.

Last lesson is, that doing good writeups is really hard!