Subj. Does anybody research the JTAG way?
I have an information what pins on PXA272 are JTAG interface. But I don't know where it's pins traced out on mainboard. The separation of PXA272 from mainboard is impossible in my case(for a while).
Does anybody know JTAG pins on mainboard for ATOM?
What tools for PC can support JTAG? Can I make a LPT-device for the connection PDA to PC by JTAG?
Did you find jtag pimout yet ? I have the same problem as yours, dead atom !
Basicly, I've seen couple connector in PDA which I believe are JTAG pinout, I've seen it in ETEN and in Atom it seem placed near the simcard holder. You'll see eight gold circle contact on the PCB, I believe six of them are JTAG pinout.
But still can't find the info about those specific pinout.
Still find the soft, mostly run under linux needed in win
I guess JTAG is my only option for waking up my atom, so if you have any info regarding this matter, would you please share with me ??
Thank you
Flashed LEOIMG.nbh from RUU_Leo_HTC_WWE_1.43.405.1_Radio_Signed_15.26.50.07U_2.04.50_22_2_Ship trying to unbrick my HTC HD2
Now when I turn it on, I get no screen, no bootloader, etc.
USB does work, appears as "Qualcomm CDMA Technologies MSM"
I found some drivers and installed it as "Qualcomm Diagnostics Interface 3197"
I have an idea to fix this..
I extracted the SPL.nb from T-Mobile_HD2_MR_Software_2.13.531.1
if I or someone can find the right Application to flash the HD2 via the "Interface 3197"
Maybe a variation of QDLTool (The HD2 shows up as ready to flash but the images are for the Streak)
Any help is very much appreciated..
I have two HD2's, one functional and one not, ready to work hand and hand with someone via IM (Ex: GTalk or AIM) to find a solution to this problem!
Does anyone have any ideas? Please help.. Don't want a $500 paper weight
brandonsisco said:
Does anyone have any ideas? Please help.. Don't want a $500 paper weight
Click to expand...
Click to collapse
Sorry man but the only way to reserect a bricked HD2 is by using a JTAG and a RIFF BOX. Do a little scimming over the thread titles in this forum. You will find plenty of threads that descuss this and some of them have post by members that offer to fix a bricked HD2 as they have the JTAG and RIFF BOX. You can also check and see ic there is a cell pbone repair shop in your area, they are more and more of these poppieg up now, heck there is one in my area now. Either finding a member here or a repair shop is probably going to be your best option cause it is going to cost you well over $200 USD to get the JTAV and RIFF BOX. A member here or repair shop will only charge you a small fraction off that price. Also the procedure you have to do to reserect your HD2 recuires you to partially desassemble your pbone and this is not for just anybody.
I read your post yesterday .utility was hesatant in posting as I wanted to see if someone might had another idea to put with yours and the both of you come up with a way to do what is said to be impssible. Wich is reserecting a bricked HD2 by just using the mini USB port to run the needed software on it to be able to reinstall a ROM. But it seems that no one has any ideas to put with yours sorry man.
I have looked through the forum and I found other guys trying to fix it without disassembling.. If I have access to the qualcomm chip and it appears in qdltool, why can't we just reprogram it via usb?
brandonsisco said:
I have looked through the forum and I found other guys trying to fix it without disassembling.. If I have access to the qualcomm chip and it appears in qdltool, why can't we just reprogram it via usb?
Click to expand...
Click to collapse
To be completely honest with you I really don't know the technical answer to your question as I have hardly any knowledge of the inner workings of the HD2 hardware. But from what I can best come up with is when a HD2 gets bricked it does something to prevent comunication between the CPU (Qualcomm Snapdragon processor) and the NAND chip that holds the ROM software. Wich intern means that you can not gain access to the NAND chip via the USB to run whatever needed software to restore it. This is why the JTAG is needed as it can reastablish comunication between the CPU and the NAND chip. Now this is just a thought of mine and I have no data to back this up with. So I maybe way off base as to why you can not use the micro USB port to reserect a bricked HD2, like I said it is just a thought I have and nothing more.
You flashed a 51 radio to a tmous. If you manage to fix it without repair or jtag, you would be the first.
I've hit a wall in my quest to improve the Samsung Gravity Smart (SGH-T589). The kernel source that Samsung released for it doesn't quite work right (no wifi, broken touchscreen drivers). I'm trying to do something about it, but my test kernels hang before ADB is able to detect and connect to the phone.
The phone is powered by the Qualcomm MSM 7227 (S1 Snapdragon @800Mhz), which I understand is supposed to have a debug UART. How do I access it?
Reading the Google Nexus i9250 thread, I took a closer look at the system board. I've highlighted what I suspect is the JTAG header (see attachment).
However, I lack both the tools and expertise to determine if that is the header, and what the pinout is (most jtag pinouts I see pictures of online are in 2-column layout).
But, I might not need that. If I understand the discussion in the i9250 thread correctly, what I need is a combination of this miniUSB breakout kit, a 619Kohm resistor, and the FTDI Friend to use to connect the UART to my PC. I'm not quite sure where I go from there, but I expect that Windows will detect the serial port and give me something to connect to via SecureCRT or the like.
Is this correct? I'd kinda like to know before I spend any money on parts
Alternately, if anyone wants to take a crack at wiring up the JTAG port, I have a spare (broken) phone I can ship out. Screen doesn't work, but it still boots which will make it perfect for testing with!
Now, if you had bothered to SEARCH you'd have found THIS post in this thread with this picture!
I actually did come across that thread, however that particular post would not have come up in a search and you'll forgive me for missing a post in a 25-page thread However, I appreciate your help nonetheless.
Next question: I have 2 conflicting schematics for wiring an LPT JTAG cable. One shows TDO wired to pin 13, the other has it wired to pin 11. Which is correct? Or should I just try it both ways?
Try both. Shouldn't happen anything bad until you connect it to 12V or so.
I'm banging my head against a wall here, trying to figure things out but not finding clear instructions.
Is it true that, in order to perform JTAG, I need to use some kind of adapter (i.e. RiffBox), or can I connect it directly to the LPT port of my PC? If I can use my PC, what software do I use to read the debug output? I'm less concerned with recovering from hard brick than I am with getting the early debug output.
I'm thinking a hacked USB approach might be simpler and less expensive. My problem is lack of tools. If anyone else has made such a cable, could I buy it off you for a reasonable price?
Hello, i have a semi bricked Samsung Galaxy S5770 Mini/Pop/Next. It is a Qualcomm MSM7227 board. I have tryied the usb UART approach, but the only thing i can get from it is AST-POWERON, and it repeats (i think it bootloops)
I am trying to find UART on board, there are some little pads around the CPU.
Sent from my GT-I9003 using XDA
Ah my TDO is wired to pin 11. You don't need riffbox if you make a LPT JTAG adapter such as the Wiggler (low voltage variant 3.3V).
There are many softwares that can handle the wiggler, such as H-JTAG, openocd and urjtag.
I used "H-JTAG" and "NoICE for ARM" on windows. It's easy to setup H-JTAG for the wiggler and you don't have to do anything from the command line.
The msm7227 platform is multi-cpu (modem cpu, applications cpu).
With the JTAG port you saw, you can access the modem cpu, which is a ARM926ej-s.
Sent from my GT-I9003 using XDA
tanks for you
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Rebellos said:
Another way, without looking for UART is just comparing what you've changed in kernel, revert it all and apply changes one by one until it stops booting again. You might also find/create some proper thread for that and ask for help. With original repo pulled from opensource.samsung and your changes applied on it commit by commit.
Click to expand...
Click to collapse
The issue here is that I'm trying to backport the MXT224 driver because the driver that's in the Samsung release is butchered beyond repair--the orientation is wrong, the resolution is wrong, the alignment is wrong.
My backported driver either fails to recognize the hardware (which is odd, because the init code uses the exact same kernel calls as the FUBAR driver for the I2C transfers), or locks up the boot process too early to get any useful debug output.
Anyway, I have the parts I need on order, all I need is for the orders to show up and a decent soldering iron and I should be in business.
Ah! The MXT224. I know this one pretty well, aswell as messup that Samsung does, configuring it in hundreds of different ways, with usually same result.
I think you don't need to port anything there. There's parameter table passed to MXT224 during init, that's probably only one thing you need to setup. You might want to reverse driver from some stock kernel, or adjust it experimentally, or simply request Samsung for proper parameter table.
There are many helping examples in various kernel arounds, sometimes it's called MXT224, and sometimes it's QT602240. This is in fact 100% same thing.
I'm not sure if any datasheet is publicily available. Though setup structures explaination should be enough, there it is:
https://bitbucket.org/gokhanmoral/s.../drivers/input/touchscreen/qt602240.h#cl-4848
For example flipping it would be changing "orient" byte in T9 structure. Probably all othere parameters you need to change are also in T9.
Thanks for the link. I managed to figure out the correct "orient" value by trial-and-error, but the screen alignment is screwed up. On a stock kernel, the top-left is 0,0. On a compiled kernel, top-left doesn't even register properly (none of the edges do). I've tried a few experimental things but nothing helped so far. I'll check out that link when I get home and hopefully find something useful.
You might also want to look into mach_aries.c and mach_herring.c files from I9000 and I9020 kernel sources. These shows pretty good how very similiar results can be done in pretty different set of T9 parameters.
I appreciate your input. I'm experimenting with different T9 values. I found a partial datasheet that shed a little light into some of the parameters.
I've managed to strip out the "piggy" (uncompressed vmlinux) from the stock kernel. Is there anything I can do with that to somehow find out what T9 parameters are used by the actual stock kernel (as opposed to what Samsung released)? I did some searching for kernel disassembly but didn't find anything that looked promising.
Can you upload it somewhere? I'd take a look into it.
Sure thing. I'll upload it tonight when I get home. Thanks!
Here it is, gzipped:
http://min.us/mrUKEtr7W
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Rebellos said:
Thanks, one more request - could you also upload .map file generated during your kernel compilation? I don't remember what was the full name of it, AFAIR it's ~70meg textfile in kernel source root or arch/arm/bin dir. Not sure though.
Also, are sources for this kernel available on github somewhere? Downloading tarball but this will take few hours more. :\
Ty in advance.
Click to expand...
Click to collapse
It's not on github at the moment. I'm just working from the kernel sources posted on opensource.samsung.com for the SGH-T589. I'll start an account tonight when I get home and upload what I have. I'll get the map file you're after uploaded too.
Okay so on my device I have two serial ports. One port is labeled J2 with 4 pin outs that I think is the UART. The seconded port labeled JPEEK3 has 6 pin outs that I think is the JTAG. Here's the problem, they aren't giving me UART and JTAG readings on my multimeter or logic analyzer.
J2 is reading like this.
3.28VGND3.28V3.28V
No data just straight to idling high.
As for JPEEK3 I'm reading this
GND.04V.04V2.95V2.95VGND
On this I'm getting data on all active pins. I tried hooking my JTAGulator up to the device to read it but every time I do the device it's stuck in reset mode.
Anyone got any idea of what these readings mean?
biomedguy said:
Okay so on my device I have two serial ports. One port is labeled J2 with 4 pin outs that I think is the UART. The seconded port labeled JPEEK3 has 6 pin outs that I think is the JTAG. Here's the problem, they aren't giving me UART and JTAG readings on my multimeter or logic analyzer.
J2 is reading like this.
3.28VGND3.28V3.28V
No data just straight to idling high.
As for JPEEK3 I'm reading this
GND.04V.04V2.95V2.95VGND
On this I'm getting data on all active pins. I tried hooking my JTAGulator up to the device to read it but every time I do the device it's stuck in reset mode.
Anyone got any idea of what these readings mean?
Click to expand...
Click to collapse
The voltage levels for the UART are OK.
UART "J2"
3.28V GND 3.28V 3.28V
It could match the signals:
VCC, GND, TxD, RxD
For UART you need to know the communication baud rate and other connection parameters. You also need to know the communication protocol at the UART layer.
The voltage levels for JTAG are OK.
JTAG "JPEEK3"
GND .04V .04V 2.95V 2.95V GND
It could match the signals:
GND, CLK, DIO, RST, VCC, GND
Which is JTAG in SWD mode.
Maybe "JPEEK3" is SWD?
For full JTAG you have this pins on "JPEEK3":
TDI, TCK, TMS, TDO, RST, VDD, GND
If RST is missing in JTAG, the problem is to get the target into debug mode if the targer has its own power supply.
Appreciate the help, never considered the pinouts for JPEEK3 to be SWD.
The board doesn't technically have it's own supply, the power comes from other boards that it's connected to, in order to power on. Should I figure out a way to power it on with a power bank in that case?
As for the UART, I have a DSLogic Plus, should I just test multiple baud rates and see what happens? I'm not sure what other protocols and communications to look for other then that.
biomedguy said:
Appreciate the help, never considered the pinouts for JPEEK3 to be SWD.
The board doesn't technically have it's own supply, the power comes from other boards that it's connected to, in order to power on. Should I figure out a way to power it on with a power bank in that case?
As for the UART, I have a DSLogic Plus, should I just test multiple baud rates and see what happens? I'm not sure what other protocols and communications to look for other then that.
Click to expand...
Click to collapse
It is a question of whether the board is powered from an external source or only from the JTAG programmer (SWD). For JTAG / SWD, it is better if the target is powered only from the JTAG programmer (SWD), unless it is required to power other peripherals and cover power requirements. For JTAG (SWD), there must be direct JTAG (SWD) programmer support for a specific target (MCU), debug mode, Flash write, and so on. Each MCU has a different protocol and must be directly supported by the JTAG (SWD) programmer or control software. For JTAG (SWD) communication, you can change the communication speed arbitrarily (it is not fixed), if it fails to connect to the target (MCU), you can reduce the communication speed.
For the UART, the communication speed (connection) is precisely determined in advance, you must know it or analyze the output data (timing of given bytes using DSLogic Plus ) if it is sent natively on the UART interface (boot log). The protocol on the UART interface also needs to be known if it is not a shell terminal output.
Well hot dog, that's a lot of solid info. Appreciate it, really.
I just got a flyswatter2 in the mail, hopefully that'll be compatible with the AT91 Atmel MCU on the board, apparently it's using an ARM7 processor. Good to know to not power on the board like I have been with the JTAGulator and DSLogic.
You wouldn't happen to know how to locate the configuration memory for the FPGA, now would you? I'm talking with my cousin whose an EE major, and he was asking for it. I'm not even sure how that'll help with getting into the JTAG.
biomedguy said:
Well hot dog, that's a lot of solid info. Appreciate it, really.
I just got a flyswatter2 in the mail, hopefully that'll be compatible with the AT91 Atmel MCU on the board, apparently it's using an ARM7 processor. Good to know to not power on the board like I have been with the JTAGulator and DSLogic.
You wouldn't happen to know how to locate the configuration memory for the FPGA, now would you? I'm talking with my cousin whose an EE major, and he was asking for it. I'm not even sure how that'll help with getting into the JTAG.
Click to expand...
Click to collapse
Atmel AT91 MCU is supported by OpenOCD. Flyswatter2 works with OpenOCD. From the FT2232H chip used by Flyswatter2, I made a programmer for SPI EEPROM [https://geekdoing.com/threads/unbrick-mi-band-3-with-without-nfc.700/]
I have never used Field Programmable Gate Arrays (FPGA), always only MCUs, I will not advise you in this area. Unfortunately. FPGA arrays have configuration memory as an external memory chip.
The JTAG programming interface is also used for FPGA arrays. FPGA and MCU are completely different technologies. Custom MCUs can also be created using an FPGA array.