FORUMS
Remove All Ads from XDA

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

59 posts
Thanks Meter: 21
 
By BinaryDroid, Member on 27th November 2009, 11:26 PM
Post Reply Email Thread
7th May 2010, 09:21 PM |#601  
Member
Thanks Meter: 1
 
More
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.

###
[email protected]:~/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
7th May 2010, 10:41 PM |#602  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Quote:
Originally Posted by sorenjul

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?
7th May 2010, 10:59 PM |#603  
Member
Thanks Meter: 0
 
More
Quote:
Originally Posted by ezterry

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
8th May 2010, 01:57 PM |#604  
Member
Thanks Meter: 1
 
More
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:
8th May 2010, 02:30 PM |#605  
Member
Thanks Meter: 0
 
More
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
8th May 2010, 02:52 PM |#606  
Member
Thanks Meter: 1
 
More
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
9th May 2010, 09:34 PM |#607  
Member
Thanks Meter: 1
 
More
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:
[email protected]:~/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
9th May 2010, 11:30 PM |#608  
ezterry's Avatar
Retired Recognized Developer
Flag Asheville, NC
Thanks Meter: 1,005
 
Donate to Me
More
Quote:
Originally Posted by sorenjul

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...

Quote:
Originally Posted by sorenjul

Code:
[email protected]:~/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)

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.
10th May 2010, 01:12 AM |#609  
Member
Thanks Meter: 0
 
More
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
10th May 2010, 11:03 AM |#610  
Senior Member
Thanks Meter: 809
 
More
Hi!

i also would recommend to examine the soldered wires first.
Quote:
Originally Posted by sorenjul

...
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
11th May 2010, 12:11 PM |#611  
Senior Member
Thanks Meter: 809
 
More
Direct NAND access for MSM720x with OpenOCD
Hi!

just grabbed the latest source code of OpenOCD.
http://openocd.git.sourceforge.net/g...nocd;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/g...1c42;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=ke...oid-msm-2.6.27

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

the header:
https://android.git.kernel.org/?p=pl...514d2;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
Post Reply Subscribe to Thread

Tags
jtag

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes