If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

important information about "hanging" or "rebooting" K790 phones.

K790 Phone hang

Only Applicable for K790!

Background:
One of the main reasons for permanent phone hangs at start up or standby
can be resolved by replacing two resistors under the Bluetooth cavity.

Instruction:
ROA (PCB) with revision R3A and R3B have not been modified.
ROA (PCB) with revision R3C has the new resistor values already from
factory.
ROA (PCB) with revision R3D has a new version of Dolphin 2 which prevents
the problem and they SHOULD NOT have the resistors replaced.

For ROA revision R3A and R3B with permanent phone hang at start up or
standby:
Change:
R1404 to 470 ohms, REP 621 003/47.
R1405 to 4.7k ohms, REP 621 004/47
Both resistors are located under the Bluetooth cavity
Attached Thumbnails

The Following 5 Users Say Thank You to GSM™ For This Useful Post:

Case:
Let's say you have a DB2020 phone with some GDFS issue, say you wrote K800 firmware to a K790 and now you have "no network".

Solution:You'll have to rewrite the original GDFS. Sadly, most users never back it up before proceeding with whatever operation they intended to do in the first place. This is done through the "Read GDFS" button in SETool, btw . it will produce a .bin-file named with the phones IMEI and can be found in your SETool basedir. Take good care of it.

Now, lets say you didn't back up the phones GDFS and did something to screw it up. Then you have a problem, because rewriting it with another phones GDFS will screw the security units and the phone will be bricked. Generally a bad thing, right ?.

Luckily, there is a way to solve this and the procedure is as follows:

Use only COM/UFS interfaces!

1 (Optional): Back up the corrupt GDFS (yes, even though it's corrupted, so you have a full backup just in case). Again: "Read GDFS". Move it to a safe place on your HD, this is to avoid accidentally deleting it and for avoiding confusion with all the other txt-files that will appear later on.
2: Create a scriptfile (a normal txt-file will do) with the following contents:

Now save it. Name it "readsecunits.txt" or whatever. Select the file in SETool's MISC-field and press "Write SCRIPT".

All the read units will be stored in a single file named by the phone's IMEI.
rename it as "secunitsbackup.txt" to avoid confusion

3: Apply the GDFS from a working DB2020 phone.
- Read it out from the source phone (it will be stored in the SETool basedir named by the source phone's IMEI)

- Check "Format GDFS" in "Settings" and write it to the damaged phone by selecting it in the MISC-field and pressing "Write GDFS". If the phone in question is OTP/FLASH CID52, DO NOT CHECK "Format GDFS"

Do NOT turn the phone on afterwards.

4: Now, you'll have to write back the original units. Apply the "secunitsbackup.txt" you created by selecting it in the MISC-field and pressing "Write SCRIPT".

Voila, it should have done the trick.
I'll ask the_laser to produce some DB2020 GDFS files in case you don't have a working phone to read from.

Solution:
Either pick a random reason (and that won't do much good for your phone )or do the following to see if the phone itself can provide you with a hint:

1: Open HyperTerminal (Start->Programs->Accessories->Communications).
2: Configure a name for the connection. I've called mine "Debug".
3: Select the proper COM port.
4: Configure baudrate and press "OK".
5: In the "Transfer"-menu, click "Capture Text", then choose a path and name for the log. You will see that the "Capture" indicator has been activated.
6: Attach a powered-off phone (the phone might start charging, this is OK). Give it a minute or two to run selftests, then post the captured text as an attachment if you want an opinion from us.

what to do ? phone was working before !!! (variant: phone was dead before)

A:

that is hardware problem and nothing to do with software. usually it is bad soldered flash chip.
latest mid-range semc phones quality is below zero.

as last resort, you can try to raise voltage on FLASH VPP upto 12v
(for start, try to flash it with dcu60, it also has increased voltage)

but what say to customer if phone works before servicing?
have no idea - think yourself- that is risk that you including in each service cost.
sadly, but such thing can be happened - flash sector can read good, but fails on erase/write.

Q:
i trying to service w810/w300/z530/z550/k310/k510 phone and getting
such result