C Series EEPROM research

[hedak]

Hallo SamyGo community,

based on D Series EEPROM research (viewtopic.php?f=23&t=5371), i'd like to start a research for C Series EEPROM.

ATM my UE46C7700 is bricked: Reboot loop every 6.5 seconds. As I think the reason for this reboot loop is the active watchdog which I'd like to disable. But there's no time to do it via Exlink, so I have to do it in hardware (AFAIK). So I want to dump the EEPROM, modify the watchdog bit and write the modified dump back.

From my PS3 modifying I still have a Teensy++ 2.0 usb dev board. IMPORTANT: As described here (http://www.pjrc.com/teensy/3volt.html) my teensy board is operating at 3.3V. Based on the sketch found here (http://wiki.samygo.tv/index.php5/Ethern ... ino_sketch) I wrote a Teensy++ 2.0 compatible sketch for just reading and writing the I2C EEPROM (see attachment). How to set up the environment for teensy in conjunction with Adruino is explained here: http://www.pjrc.com/teensy/tutorial.html

On the following picture the wire colour indicate:

red: VCC (3.3V), ready 1 second after relais click
black: GND
green (right): WP (not used yet), just measured 3.3V, so WP is active
silver: I2C Data (SDA)
green (top): I2C clock (SCL)

DSC_0289_resized.jpg

On the teensy board GND is connected with EEPROMs GND. Teensy's D0 (SCL) is connected to green wire (SCL). Teensy's D1 (SDA) is connected to silver wire (SDA). WP and VCC wires are not connected, just isolated at the end.

Picture of wired teensy board follow.

Now the interesting part...

I did the following:

0) disconnect TV from power
1) connected GND, SDA, SCL between teensy and EEPROM
2) connected teensy via usb to pc
3) compiled and flashed my sketch to teensy
4) used terminal application hterm (http://www.der-hammer.info/terminal/) to connect to serial com port (115200 baud, 8N1, 'Newline at': 'LF', 'Send on enter': 'LF')
5) pressed the button 'DTR' in hterm to let the sketch become ready -> teensy's LED starts flashing
6) connected TV to power
7) turned TV on
8) waited 2-3 seconds
9) send the following to teensy via hterm: http://IP/read?format=1&device=80&size=16384&addr=0
(of course the leading http stuff is irrelevant here)
(I had to portion the dump because of missing time...)
-> TV restarted
10) waited 2-3 seconds
11) send the following to teensy via hterm: http://IP/read?format=1&device=80&size=16384&addr=16384
-> TV restarted
12) waited 2-3 seconds
13) send the following to teensy via hterm: http://IP/read?format=1&device=80&size=16384&addr=32768
-> TV restarted
14) waited 2-3 seconds
15) send the following to teensy via hterm: http://IP/read?format=1&device=80&size=16384&addr=49152
16) saved the received data as raw and then four times removed the sketch print stuff -> resulting file size is 65536

I did this several times. The results are completely different from juuso' here (viewtopic.php?f=23&t=5371#p38958) although the dump contents didn't change after reading several times... So there shouldn't be any wiring problems.

In my sketch I then added a line to print the I2C clock used: 100kHz.
Because its annoying to portion the dump everytime I changed the file Arduino\hardware\teensy\cores\teensy\Arduino.h by adding these two lines at the end to work at 400kHz:
#undef TWI_FREQ
#define TWI_FREQ 400000L

Then a repeated the procedure above and in step 9) I ran: http://IP/read?format=1&device=80&size=65536
The whole dump is binary exactly the same as the assembled four portioned dumps.

If you compare my and juuso' dumps you will see, that there seems to be no relation... The (for me) interesting values at address 0x51D1 look completely different. So sad, that I cannot change any value via software and compare this dump

The most promising address in my dump seems to be 0xfcd6:
in juuso' dump at 0x51D0: 00 00 00 00 00 00 02 00 9E 10
in my dump at 0xFCD5: 00 01 00 00 00 00 00 00 1F 10

What do you think? Any help/suggestions are very appreciated

[juusso]

In my case i have had spare mainboard, where i could check those values and bring back to live my bricked mainboard (which is currently dead again - wrong bootloader was flashed.... totaly dead...).

We need at least one, who could connect and make dumps on fully operating tv. Switch service values one by one on/off and identify addresses.

Do you know some service man who could borrow mainboard for you?
I don`t wonder that eeprom dumps are completelly different. Many times i did full dump and here were a lot of bytes (>60% i think) that were not permanent, changed from boot to boot.

[hedak]

Unforunately i dont know any service man.
What surprises me is that my dumps remain the same after each reboot!

BTW i attached my dump to my previous post - would you be so kind and have a short look at it? What du you think is the risk of trying to change the bit at 0xFCD6 to 0? Should i try?

Another option could be to reset the EEPROM (http://wiki.samygo.tv/index.php5/UnBric ... 8EEPROM.29) to reset the UART funtion to default (is now DEBUG) to find the bit change. But i assume a bunch of bits would change then, right?

And the first 7 byte of my dump surprise me somehow! ...

Do you know if there exists software to sniff I2C? So i could get the adresses of the values askes at boot

[beatfreak]

last year i sold my UExxC6000 (VAL6DEUC) to a buddy together with a C6700 Mainboard (as i had already bought my C6500), i dont know if he swapped the boards already, maybe he needs a little bump to do that. Do you think the C6000 MB could be a suitable reference to a C7700 ?

[hedak]

Ok, maybe an option! Braunschweig isn't that far away from you (and your buddy?)

But i cannot say if the C6700 is suitable to a C7700. But i guess juuso can

[TOMillr]

Uh... sorry for highjacking the thread, but I'm trying to replace the mainboard on my C6000 to get the PVR function going. You don't happen to have access to a C6500, 6700 or 6800 board that I might use to see if the specific board is compatible with my tv set?

Already bought one c6700 board already that doesn't seem to to work, so I'm looking for other options... I'm from Cologne btw.

[sbav1]

What surprises me is that my dumps remain the same after each reboot!

Well, perhaps that's because you are apparently trying to access the wrong EEPROM..
IC8002 on your mainboard is not main SoC (Valencia) EEPROM, it's FRC chip (Micronas/Trident) EEPROM instead.

Main SoC EEPROM in UE*C7XXX will be much more likely 256Kb / 32KB in size (AT24C256B or an equivalent- search for 8-pin chip marked as ATML*2EB etc.)

[hedak]

Great finding! Accidentally i found your posting here a few hours ago: viewtopic.php?f=9&t=4707&start=10#p35663

I think your right. In my MB there are also two other 8 pin EEPROMS: 4256BRP and S24CS0. I think it's the first one (placed on the backside), cause its wired to the SoC directly:

DSC_0273_resized.jpg

DSC_0272_resized_marked.jpg

The S24CS0 is located on the top side:

DSC_0265_resized.jpg

DSC_0261_resized_marked.jpg

In the afternoon i will try to read the 4256BRP. Just need to solder some wires on the test points

@sbav1: do you have any dump of UE*C7XXX's SoC EEPROM?

THX

EDIT: to summarize:
4256BRP is SoC EEPROM
S24CS0 is MICOM EEPROM

[hedak]

Sorry for posting twice succesively, but i think its useful if anyone wants to link to the post with a C7700 SoC EEPROM dump!

sbav1 was right, its been the 4256BRP chip. The dump is attached. Its comparable to juuso' dump. There's only the question where the watchdog flag is located. It's definitively NOT at 0x51D1. I think it might be at 0x6D51. Why? Its embedded in several 0xFF and the ASCII-String 'r.t.n.u.w.' is located not far away in both dumps.

Feedback and suggestions would be great

PS: Dumped twice and both are equal

[juusso]

Looking at dump of your SoC eeprom and comparing it to one of my D6750 i (think, that i) identified some info-blocks that are similar in both dumps and seems, they also are in similar sequence, so i bet for addresses 0x6D50 to 0x6D5B having our interesting service menu values like values on D series at addresses 0x51D0 - 0x51E2.

IMHO first shot to address 0x6D51 (=01, on) changing to 00. (watchdog???)

BUT! Before to do that important shot, you could check if my thinking is correct. According D series, the first value in this byte consequence should be rs232 value and it is set to 00 (00, debug). For testing purposes you should set 0x6D50 to 01 (uart) and after reboot (or as soon as you change value) your Exlink log should disappear. Changing value back to 00 (debug) should make your Exlink vital again. Follow me?

In all cases, am i correct or not, nothing bad can happen, you can set values back to original state. Just don`t change to much, you become lost in hex