SUCCESS! De-Bricking Dreams - Complete JTAG Testpoints! UPDATE! 04/07/10

sorenjul · May 7, 2010

jtag error while connecting to target

Hi

When I try to connect via jtag to my magic 32a I get the following errors from openocd.

###
ubuntu@ubuntu:~/Downloads/flash$ sudo openocd -f dream.cfg
Open On-Chip Debugger 0.4.0 (2010-04-26-19:27)
Licensed under GNU GPL v2
For bug reports, read

trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
dcc downloads are enabled
fast memory access is enabled
Info : clock speed 6000 kHz
Info : JTAG tap: arm9.cpu tap/device found: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0)
Warn : JTAG tap: arm9.cpu UNEXPECTED: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: arm9.cpu expected 1 of 1: 0xa01700e1 (mfg: 0x070, part: 0x0170, ver: 0xa)
Warn : Unexpected idcode after end of chain: 32 0x00000000
Warn : Unexpected idcode after end of chain: 64 0x00000000
Warn : Unexpected idcode after end of chain: 96 0x00000000
Warn : Unexpected idcode after end of chain: 128 0x00000000
Warn : Unexpected idcode after end of chain: 160 0x00000000
Warn : Unexpected idcode after end of chain: 192 0x00000000
Warn : Unexpected idcode after end of chain: 224 0x00000000
Warn : Unexpected idcode after end of chain: 256 0x00000000
Warn : Unexpected idcode after end of chain: 288 0x00000000
Warn : Unexpected idcode after end of chain: 320 0x00000000
Warn : Unexpected idcode after end of chain: 352 0x00000000
Warn : Unexpected idcode after end of chain: 384 0x00000000
Warn : Unexpected idcode after end of chain: 416 0x00000000
Warn : Unexpected idcode after end of chain: 448 0x00000000
Warn : Unexpected idcode after end of chain: 480 0x00000000
Warn : Unexpected idcode after end of chain: 512 0x00000000
Warn : Unexpected idcode after end of chain: 544 0x00000000
Warn : Unexpected idcode after end of chain: 576 0x00000000
Warn : Unexpected idcode after end of chain: 608 0x00000000
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Info : JTAG tap: arm9.cpu tap/device found: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0)
Warn : JTAG tap: arm9.cpu UNEXPECTED: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: arm9.cpu expected 1 of 1: 0xa01700e1 (mfg: 0x070, part: 0x0170, ver: 0xa)
Warn : Unexpected idcode after end of chain: 32 0x00000000
Warn : Unexpected idcode after end of chain: 64 0x00000000
Warn : Unexpected idcode after end of chain: 96 0x00000000
Warn : Unexpected idcode after end of chain: 128 0x00000000
Warn : Unexpected idcode after end of chain: 160 0x00000000
Warn : Unexpected idcode after end of chain: 192 0x00000000
Warn : Unexpected idcode after end of chain: 224 0x00000000
Warn : Unexpected idcode after end of chain: 256 0x00000000
Warn : Unexpected idcode after end of chain: 288 0x00000000
Warn : Unexpected idcode after end of chain: 320 0x00000000
Warn : Unexpected idcode after end of chain: 352 0x00000000
Warn : Unexpected idcode after end of chain: 384 0x00000000
Warn : Unexpected idcode after end of chain: 416 0x00000000
Warn : Unexpected idcode after end of chain: 448 0x00000000
Warn : Unexpected idcode after end of chain: 480 0x00000000
Warn : Unexpected idcode after end of chain: 512 0x00000000
Warn : Unexpected idcode after end of chain: 544 0x00000000
Warn : Unexpected idcode after end of chain: 576 0x00000000
Warn : Unexpected idcode after end of chain: 608 0x00000000
Error: double-check your JTAG setup (interface, speed, missing TAPs, ...)
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
###

Do any of you know why?

Regards Soren Jul

ezterry · May 7, 2010

sorenjul said:
Hi

When I try to connect via jtag to my magic 32a I get the following errors from openocd.

... cut ...

Do any of you know why?

Regards Soren Jul

Its not reading the processor Id correctly..

May be a few reasons.

A: did you start openocd with the phone already in blue light mode? The processor needs to be running for jtag to notice it. Thus best to enter blue light mode before starting the openocd app.

B: are you sure all the wires are securely attached

C: verify vref is 2.6v .. while jtag is running (make sure you don't short anything with the multi meter)

D: what type of jtag adapter are you using? can it support that speed?

bart9984 · May 7, 2010

ezterry said:
Its not reading the processor Id correctly..

May be a few reasons.

A: did you start openocd with the phone already in blue light mode? The processor needs to be running for jtag to notice it. Thus best to enter blue light mode before starting the openocd app.

B: are you sure all the wires are securely attached

C: verify vref is 2.6v .. while jtag is running (make sure you don't short anything with the multi meter)

D: what type of jtag adapter are you using? can it support that speed?

I confirm what said by ezterry, the id is wrong, in my case it happened cause of the gnd wire not properly fixed, or one of the other wires too. Try also to disconnect the +5v from the serial cable, in my case I used it connected to start the phone and serial console and then I used to disconnect it. When it was connected openocd had problems.

Enjoy,
bart99

sorenjul · May 8, 2010

Hi

Thanks for the reply

A: I did enter blue led mode before starting openocd. Serial debug is listed below
boot reason: PM_KPD_PWR_KEY_ON_RT_ST

(PowerOn Status,Boot Reason)=(1,1)
NAND_FLASH_READ_ID : SAMSUNG_512MB_FLASH_256MB_SDRAM

ARM9_BOOT_MODE1

B: I did not solder the wires to the board myself - a friend did it at my old company under a microscope. Any way to test the connecttion with the jtag debugger? I left out the RTCK signal like Bart99 cause it is (impossible) to solder between the cpu and the shield case.

C:Vref is supplied from a lab voltage source so it should be ok

D: I'm using the Olimex arm-usb-ocd. I can't seem to find out if the debugger is powered by the USB or do I have to supply voltage to the debugger.

Regards Soren Jul

C:

bart9984 · May 8, 2010

Hi,
Well the debugger is powered by usb, it has a led that should became green. But I don't think your problem it's about power, it seems to be a lost connection one. Try removing battery and usb and with a multimeter check there are not cortos between wires and gnd or between wires themself. In my case a common value of the resistance between wires and gnd was 400 to 800, a good connection one should be about in the middle of the range. What I'm saying is what i've experiencenced in my tries, also me had some problem at the beginning.

Enjoy,
bart99

sorenjul · May 8, 2010

Oh I guess I just have to borrow a scope and check each of the signals and see if some of them are quiet. My multimeter is way to slow to measure any of the voltages I will not get any readings at all.

Just a questions - how long wires did any of you use. Mine could easily be shorter, hope I don't have too bad signal quality. I just noticed the the ribbon cable on the jtag debugger has a 50/50 ground/signal to keep crosstalk down.

If the debugger is equipped with new fast output buffers (can't buy those old slow ones any longer) I surely will have significant crosstalk on my interface.

Regards Soren Jul

sorenjul · May 9, 2010

better results but still not there

Hi

I shortened the jtag wires and resoldered the and now I think I'm a step closer to the goal line.

When I start openocd I get:

Code:

ubuntu@ubuntu:~/Downloads/flash$ sudo openocd -f dream.cfg 
Open On-Chip Debugger 0.4.0 (2010-04-26-19:27)
Licensed under GNU GPL v2
For bug reports, read
	
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
dcc downloads are enabled
fast memory access is enabled
Info : clock speed 6000 kHz
Info : JTAG tap: arm9.cpu tap/device found: 0x301700e1 (mfg: 0x070, part: 0x0170, ver: 0x3)
Warn : JTAG tap: arm9.cpu       UNEXPECTED: 0x301700e1 (mfg: 0x070, part: 0x0170, ver: 0x3)
Error: JTAG tap: arm9.cpu  expected 1 of 1: 0xa01700e1 (mfg: 0x070, part: 0x0170, ver: 0xa)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 6
Info : arm9: hardware has 2 breakpoint/watchpoint units

And when I try to "halt" the processor I get

Code:

> halt
invalid mode value encountered 20
cpsr contains invalid mode value - communication failure
Command handler execution failed
in procedure 'halt' called at file "command.c", line 650
called at file "command.c", line 361
Halt timed out, wake up GDB.
>

And In openocd I get:

Code:

Error: invalid mode value encountered 20
Error: cpsr contains invalid mode value - communication failure
Command handler execution failed
Info : Halt timed out, wake up GDB.

Any suggestions to what my problem is. As far as I can tell the only problems could be that I did not compile and install openocd correct or else the radio ver. 6.35 is causing problems.

Best regards
Soren Jul

ezterry · May 9, 2010

sorenjul said:
Hi

I shortened the jtag wires and resoldered the and now I think I'm a step closer to the goal line.

Since my jtag wires are not exactly short I'm very curious how long yours are that you are worrying about the length...

sorenjul said:

Code:

ubuntu@ubuntu:~/Downloads/flash$ sudo openocd -f dream.cfg 
Open On-Chip Debugger 0.4.0 (2010-04-26-19:27)
Licensed under GNU GPL v2
For bug reports, read
	
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
dcc downloads are enabled
fast memory access is enabled
Info : clock speed 6000 kHz
Info : JTAG tap: arm9.cpu tap/device found: 0x301700e1 (mfg: 0x070, part: 0x0170, ver: 0x3)
Warn : JTAG tap: arm9.cpu       UNEXPECTED: 0x301700e1 (mfg: 0x070, part: 0x0170, ver: 0x3)
Error: JTAG tap: arm9.cpu  [b]expected 1 of 1: 0xa01700e1[/b] (mfg: 0x070, part: 0x0170, ver: 0xa)

bart9984:
The dream has CPU id: 0xa01700e1 .. Did the magic match that or is it 0x301700e1? I remember you indicating it was the same as the dream; but the Omnia forums seems to also have references to 0x301700e1?

sorenjul:
openocd will not send the halt command unless the CPU ID matches.. this is just defined in the CFG so easy to change; however if we know we have the right ID; it could indicate you still have a loose connection.

Code:

   set _CPUTAPID 0xa01700e1

I know both the T-Mobile G1 and Rogers Dream both are 0xa01700e1 but I have not tried a magic.

bart9984 · May 10, 2010

Hi,

During my tries I experienced both id=0x301700e1 and id=0x901700e1,
In my case if id =0x3001700e1 I was not able to use jtag cause to "halt time out error"...
another important think is Info : Embedded ICE version 6 , during my experiments I had ICE=15 and it was an error caused by not well soldered wires.
At the and I had a warning caused by the id and ICE=6 and it worked. In my config file I used set _CPUTAPID 0xa01700e1. So should be sorenjul still have not well soldered wires problem...

Cheers,
bart99

scholbert · May 10, 2010

Hi!

i also would recommend to examine the soldered wires first.

sorenjul said:
...
C:Vref is supplied from a lab voltage source so it should be ok

D: I'm using the Olimex arm-usb-ocd. I can't seem to find out if the debugger is powered by the USB or do I have to supply voltage to the debugger.

My suspicion is, there could be something wrong with the power supply environment.
As a result there could be some noise/bounce on GND of your mainboard which causes erroneous data transfers.

I got it like this:
1. Host PC -> powers Olimex USB (5V)
2. Lab voltage source -> powers Olimex USB output drivers (2.6V)
3. Battery -> powers Dream mainboard (is the source of TDO level)

Try the following...
Connect Olimex USB to your PC and attach it also to the Dream mainboard.
Do not connect the lab supply to Olimex yet.
Power up your lab supply and check if there's a potential difference between GND of your supply and the Dream mainboard.

If you measure high voltage levels between GND...
...try to minimize it by choosing the same AC supply for your host PC and the lab supply.
...try to change polarity of one of the AC plugs.
...use good GND connection between the different parts.

Other things to check have already been mentioned here...
...use short wires to your buffered adaptor (mainboard <-> Olimex USB)
...try to reduce JTAG signal speed (6000kHz is pretty fast)
...keep your environment clean (power off additional switching supplies in your AC network you do not need, e.g. laptop power supply)

Regards,

scholbert

scholbert · May 11, 2010

Direct NAND access for MSM720x with OpenOCD

Hi!

just grabbed the latest source code of OpenOCD.
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=summary

While stepping through the code i realized that there's already support for the NAND controllers of the famous S3C24xx and S3C64xx SoC's from Samsung.
There's also some interesting patch to integrate NAND access for the PXA3xx family:
http://openpxa.git.sourceforge.net/...b14f902c0def2250b465e1f7fe0e0361c42;hb=master

This project started from scratch using the NAND kernel driver for PXA as a base.
With some programming skills and basic knowledge about the OpenOCD framework it should be possible to integrate the MSM720x NAND controller as well.

Concerning MSM NAND integration...
we got some kernel drivers:
https://android.git.kernel.org/?p=k...4e01af059af08ec9bd68cb8;hb=android-msm-2.6.27

and some bootcode examples:
https://android.git.kernel.org/?p=p...3f0ca8950b20962d2dba949ec1fa92635743;hb=donut

the header:
https://android.git.kernel.org/?p=p...f9a832b330332f3a4a2a08dd5ed508d514d2;hb=donut

Of course there's source code from other/newer versions as well.

Once integrated into OpenOCD this would give us direct access to NAND flash on HTC Dream and might open the door for further investigation and/or techniques to rewrite parts of the firmware.

Any thought's are welcome

Regards,

scholbert

gymmy · May 12, 2010

hey guys,

Had a bit of a disaster today

Soldered the wires on all fine left to take a call, and come back to find the cat on my work desk playing catch the wire !!

Grrrr, anyhow to cut a long story short the ridgness of the wires i soldered on to the points has caused the jtag point to be fractured from the board

so im kinda screwed now

Never mind was all fun and games

Phone still works though so here is hoping for a serial fix for it !

G

lbcoder · May 12, 2010

gymmy said:
hey guys,

Had a bit of a disaster today

Soldered the wires on all fine left to take a call, and come back to find the cat on my work desk playing catch the wire !! Grrrr, anyhow to cut a long story short the ridgness of the wires i soldered on to the points has caused the jtag point to be fractured from the board so im kinda screwed now

Never mind was all fun and games Phone still works though so here is hoping for a serial fix for it !

G

Get rid of the cat.
Get a dog. They live on the floor so tend not to mess with anything but low hanging wires.

dr4stic · May 12, 2010

lbcoder said:
Get rid of the cat.
Get a dog. They live on the floor so tend not to mess with anything but low hanging wires.

You must be talking about either really tiny dogs, or really big dogs. Otherwise, I have a rat terrier that jumps on anything and everything... which in his younger days included things like chairs, sofas, tables, desks, kitchen counters, etc

gymmy · May 12, 2010

haha yeah tell me about , she certainly have 9-1 lifes left that for sure ! never mind, ill just have to trace out alternatives or just trash it lol

lbcoder · May 12, 2010

dr4stic said:
You must be talking about either really tiny dogs, or really big dogs. Otherwise, I have a rat terrier that jumps on anything and everything... which in his younger days included things like chairs, sofas, tables, desks, kitchen counters, etc

.... that sounds like training issues to me.

FYI: one of my dogs is also a rat terrier.
It is the most obedient and well behaved animal I've ever had. I can put it in one place and it'll stay there for a month if I don't release it, even if there were squirrels mating 10 feet away.

eleazar6 · May 13, 2010

Quick question... can I interchange AUX and primary JTAG points? I also tore off a solder pad for TDI. Can I use AUX_TDI on the other side of the board?

dflipb · May 14, 2010

I don't know if this has been suggested, (I have read through the entire thread but can't remember) but for those that aren't that skilled at soldering, wouldn't it be easier to just buy this:

(World Wide Web)gsm-technology.com/index.php/en_US,details,id_pr,7183,menu_mode,categories.html (sorry it wouldn't let me post a freakin link! argh!)

it's the JTAG adapter for the G1 so instead of trying to get in there at those micro points, you could just get a data ribbon and hook your $2 self made JTAG to this. I think that would greatly improve soldering contact problems.

Thoughts?

Keep up the great work!! I bow to your excellence!
Mark

lbcoder · May 14, 2010

dflipb said:
I don't know if this has been suggested, (I have read through the entire thread but can't remember) but for those that aren't that skilled at soldering, wouldn't it be easier to just buy this:

(World Wide Web)gsm-technology.com/index.php/en_US,details,id_pr,7183,menu_mode,categories.html (sorry it wouldn't let me post a freakin link! argh!)

it's the JTAG adapter for the G1 so instead of trying to get in there at those micro points, you could just get a data ribbon and hook your $2 self made JTAG to this. I think that would greatly improve soldering contact problems.

Thoughts?

Keep up the great work!! I bow to your excellence!
Mark

Perhaps, but perhaps not.
Those spring-loaded type contacts don't tend to be particularly reliable. I remember doing some hacker stuff that need not be mentioned, that almost everybody who used those kinds of contacts ended up having problems because they didn't connect well enough.

I guess the idea is that if you're only going to do it ONCE, then the chances of ripping the contact point off the board are fairly low.

However, the main thing that needs to be considered when soldering wires onto the board is to use wires that are NOT TOO RIGID!!!

If you use very light and thin wires, you'll most likely have no problems at all. If you use a 6GA wire you bought at home depot, you'll probably destroy everything in its path. Remember that you use BIG WIRES for BIG CURRENT. The current you'll be dealing with is NEGLIGIBLE. Even the very thinnest wire you can come up with will be enough.

bestrafer · May 16, 2010

here is my attempt to unbrick "a dream":
1. Serial wire soldered and it works (Nokia DKU-5 cable used)
2. Got LPT wiggler http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=350348768870
3. Friend of mine soldered all test-points under microscope.
4. The board is powered by battery
6. 2.6V is taken from the board itself http://www.omnia-repair.com/forum/topic/htc-dream-g1-jtag/page/2

I grabbed an OpenOCD config for Wiggler from the cyanogen wiki page:

c:\Program Files\OpenOCD\0.4.0\bin>openocd.exe -f dream.cfg
Open On-Chip Debugger 0.4.0 (2010-02-22-19:05)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
parport port = 0x378
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
dcc downloads are enabled
fast memory access is enabled
Info : clock speed 500 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.

Should I connect also the serial +5v voltage to let openocd to detect target as bart9984 suggested:

Now to let openocd to detect target I had to connect also the serial +5v voltage, if not I had a "FAILED: all ones" error by openocd. After openocd started i removed the +5v connection because with it attached I can't write to serial console (maybe is only a problem of mine and not general)

Which pin should be used for +5v voltage?

SUCCESS! De-Bricking Dreams - Complete JTAG Testpoints! UPDATE! 04/07/10

Member

Retired Recognized Developer

Senior Member

Member

Senior Member

Member

Member

Retired Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Member

Senior Member

Senior Member

Similar threads

Top Liked Posts