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
green (right): WP (not used yet), just measured 3.3V, so WP is active
silver: I2C Data (SDA)
green (top): I2C clock (SCL)
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:
#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
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.
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
- SamyGO Project Donor
- Posts: 590
- Joined: Tue Aug 23, 2011 9:03 am
- Location: Hamburg
FYI: you can close your ssh session with SamyGO with
Code: Select all
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.
Well, perhaps that's because you are apparently trying to access the wrong EEPROM..hedak wrote: What surprises me is that my dumps remain the same after each reboot!
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.)
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:
The S24CS0 is located on the top side: 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?
EDIT: to summarize:
4256BRP is SoC EEPROM
S24CS0 is MICOM EEPROM
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
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