[solved] Help for a bricked PM3 Easy

spp2000 · 2018-08-29 21:10:02

Hello all,
after half an hour that I received my PM3 Easy, I bricked it trying to upgrade the fw (iceman fork if I remember well)
I already tried to connect it with the button pressed but my Win7 won't recognize it at all.
So I bought a Jlink (maybe a clone) and followed the instructions to connect it to the PM3:
TMS to TMS, TDI to TDI, TDO to TDO, TCK to TCK, GNG to GND and to power the PM3 I used its USB port.
I double checked these connections.
I used Jlink Flash 5.00 because this the oldest version I can download from Segger website.
I followed the directions (in this forum annd in this video video to create a new project and to configure it but I receive this error in the status window:

Connecting ...
 - Connecting via USB to J-Link device 1
 - Device "AT91SAM7S512" selected.
 - Target interface speed: 200 kHz (Fixed)
 - VTarget = 2.141V
 - TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
 - TotalIRLen = ?, IRPrint = 0x..000000000000000000000000
 - Executing init sequence ...
    - ERROR: Could not perform target reset
 - ERROR: Failed to connect.
Could not perform custom init sequence.

I tried J-link commander too:

Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: 87461523
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDBFull
VTarget = 2.154V
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000001
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000001
No devices found on JTAG chain. Trying to find device on SWD.
No device found on SWD.
Failed to identify target. Trying again with slow (4 kHz) speed.
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000

****** Error: Failed to measure TotalIRLen.
Info: TotalIRLen = ?, IRPrint = 0x..000000000000000000000000

****** Error: Failed to measure TotalIRLen.
No devices found on JTAG chain. Trying to find device on SWD.

**************************
WARNING: RESET (pin 15) high, but should be low. Please check target hardware.
**************************

No device found on SWD.
No device found at all. Selecting JTAG as default target interface.
J-Link>

I don't have a so deep knowledge so I can't understand where is the problem.
Can you help me?
Thanks
spp2000

PS: regarding the Warning, pin 15 in my case is disconnected.

Last edited by spp2000 (2018-10-02 21:50:23)

gator96100 · 2018-08-30 02:28:16

Is the Proxmark powered? You need to connect the 3v3 pin of the JTAG Emulator Debugger to the Proxmark or power it over USB.
Why don't you use the newest version of Jlink Flash?

spp2000 · 2018-08-30 08:04:10

Thank you gator96100,
the power led of the PM3 is on. I tried also to not use the USB and power it with the 3.3 of the J-link, but I receive the same error.
I have used this version because in various "unbricking guides" they used the old version 4.50 (even if at that time a newer version was available).
I will try again using the latest version 6.34c.

------------

On another PC with a fresh installation of J-Flash 6.34c I receive the same error:

Connecting ...
 - Connecting via USB to J-Link device 1
 - Device "AT91SAM7S512" selected.
 - Target interface speed: 200 kHz (Fixed)
 - VTarget = 2.154V
 - TotalIRLen = ?, IRPrint = 0x..000000000000000000000001
 - TotalIRLen = ?, IRPrint = 0x..000000000000000000000001
 - Executing init sequence ...
    - ERROR: Could not perform target reset
 - ERROR: Failed to connect.
Could not perform custom init sequence.

Last edited by spp2000 (2018-09-01 04:54:43)

spp2000 · 2018-08-30 17:07:08

Now I followed the instructions from Elechouse:
Jtag tool for Proxmark3
Here you can find the video and the J-Flash ARM v4.50.
Here is the output in my case:

- Connecting via USB to J-Link device 1
 - J-Link firmware: V1.20 (J-Link ARM V8 compiled Nov 28 2014 13:44:46)
 - JTAG speed: 5 kHz (Fixed)
 - Initializing CPU core (Init sequence) ...
    - Initialized successfully
 - JTAG speed: 5 kHz (Auto)
 - ERROR: Auto detection of CPU clock frequency is not supported for this core
 - ERROR: Failed to connect

If I try to go forward, by fixing the CPU clock frequency to 32kHz (as autodetected in the video), I receive this output:

 - Connecting via USB to J-Link device 1
 - J-Link firmware: V1.20 (J-Link ARM V8 compiled Nov 28 2014 13:44:46)
 - JTAG speed: 5 kHz (Fixed)
 - Initializing CPU core (Init sequence) ...
    - Initialized successfully
 - JTAG speed: 5 kHz (Auto)
 - CPU clock frequency: 32 kHz
 - WARNING: Unexpected core ID. (Found: 0x00000000, Expected: 0x3F0F0F0F, Mask: 0xFFFFFFFF)
 - J-Link found 0 JTAG device. Core ID: 0x00000000 (ARM9)
 - Connected successfully

It seems that it won't recognize the CPU.
Any help? suggestion?
thanks
spp2000

jump · 2018-08-30 17:37:12

Disclaimer: I don't have a PM3 Easy to test/check.

This looks like a communication issue as you're only reading 0's. I would therefore try swapping TDI and TDO in case they were mislabeled.

spp2000 · 2018-08-30 21:40:28

Hi Jump, thank you very much for your suggestion.
Unfortunately I receive the same output with swapped TDI & TDO:

Unexpected core ID. (Found: 0x00000000, Expected: 0x3F0F0F0F, Mask: 0xFFFFFFFF)

To exclude a problem of contacts, soldering, etc I have verified, for each of the required pins, that there is continuity from the pins of the J-link port to the pins of the AT91SAM7S512.
In other words, with the help of the AT91SAM7S512 datasheet I have verified with a multimeter (under a microscope )that each pin of the J-link port reaches the CPU.

datasheet

What do you think at this point? Is possible that the CPU was defective? Or?

gator96100 · 2018-08-30 22:40:58

I did have a similar issue, see: [Solved] Error while un-bricking pm3 easy
Checking with a multimeter and a microscope might not do the trick. I did check the pins on my Proxmark with a microscope and everything seemed to be connected, retinning the pins did solve it.
Other than that, your J-Link could be defective.

spp2000 · 2018-08-30 23:48:42

Ok gator96100, I'm able to retin all the pins of the ATMEL. I will try tomorrow... it needs fresh eyes!
Thanks for the suggestion!

jump · 2018-08-31 00:19:46

Considering pin1 on J-Link is labelled VREF, it's highly probable that they use it internal for level shifting (i.e. it might not be providing power). And you're not mentioning that you're connecting it.
Also in your first post, one can read "Vtarget 2.141V" which might be too low for the processor.

Try to power the Proxmark through USB and connect VCC to VREF on your J-Link if it's not already the case.

spp2000 · 2018-08-31 11:00:27

You are right, jump, I missed this information. I have powered the PM3 with USB & connected the 3.3V pin of the Proxmark JTAG to the VTREF of the J-link (pin 1), so J-link can read the correct voltage of the CPU; now I correctly read that the CPU receive about 3.3V. Is this right? Anyway in this situation too I have the same problem (all 0's from CPU). Thanks!

Last edited by spp2000 (2018-08-31 11:01:27)

spp2000 · 2018-08-31 20:55:12

Retinned all the pins, checked all the other solder joints, checked some resistors near the CPU...everything seems to be ok. I'm confused.

1. Could be really a defective J-Link? I'm planning to check the JTAG connection with another microcontroller. Could be a good idea? In what kind of devices I can find a compatible microcontroller?

2. I have also checked with a scope that "something" travels on the TDO line when I try to connect with J-Flash. Could be an evidence that the Proxmark CPU is speaking but the J-Link doesn't ear?

3. I found this genuine SEGGER J-Link "EDU" version. Can I use it in the same way to JTAG the Proxmark (is compatible?). Anyway, for the moment I would avoid to buy another device without a diagnosis.

Thanks!!!

grauerfuchs · 2018-08-31 21:59:16

I've certainly seen bad JTAG devices before, but it could also be the cable or connector. If you got a cheap one (very likely a knockoff at the price/link you listed), QA is frequently low if present at all. Definitely try on another supported microcontroller. It's an excellent way to see on which side the trouble lies.

If you have a multichannel scope, check the TDO line (channel A) against the TCK line on channel B. You should be seeing changes in state of TDO happening alongside the clocking (TCK) pulse or with the clocking pulse at a multiple of the TDO changes. If they're not reasonably close to synchronized, it's possible the chip hasn't even entered debug/JTAG mode.

The "EDU" versions are definitely cheaper than full retail, but my past experience is that you need to prove you're part of an educational institution to be able to buy anything discounted that way. I think it best if we first find out whether it's an issue of the JTAG box or the PM3 Easy before considering buying something else.

Last edited by grauerfuchs (2018-08-31 22:40:24)

spp2000 · 2018-09-02 01:14:41

Hi all,
unfortunately I found no compatible microcontroller to test the J-Link.

I used a mini 4 channel oscilloscope (DS203) to visualize the 4 lines. Don't blame me!
As soon as I click "connect" I see:

I don't know how the 4 signals should be, anyway TDO is always flat. To be sure, I tried also swapping channels and probes.
In a previous message I said that I saw something on the TDO line. I've probably only seen spikes (I used another scope with autorange mode).
What can you say by looking this snapshot?

Thanks! You are really all very stimulating in this forum with all your suggestions!

Last edited by spp2000 (2018-09-03 07:55:00)

gator96100 · 2018-09-02 02:20:27

I tooked up a logic analyzer with trigger on raising TMS pin. Using a buspirate and RDV2. I could configure jtag decoder if needed.

Initial packet:

Full view:

Last edited by gator96100 (2018-09-02 02:30:25)

grauerfuchs · 2018-09-02 02:31:00

@spp2000 - Without taking the time to translate the commands sent by the J-Link, it looks from a quick glance to be correct with the exception of no data returned and no signal on the line. I suspect either the pins aren't connected properly (possibly soldering issue) or there's something shorting the TDO pin to ground. Try looking at the traces from the TDO pin both on the ARM and on the FPGA. It's possible the PM3 Easy is using the port for both of them, but I can't be sure until I get a chance to pull one apart and see how it's wired. Unfortunately, the scope traces above don't quite let us see if it's the J-Link or the PM3 that's shorting out the TDO. Can you try taking a set of scope traces with all pins connected except TDO, and do the following:
1. Connect scope probe to PM3 TDO pin but do not connect PM3 TDO port to J-Link
2. Try to establish connection on JTAG. We know it will fail, but the scope trace will tell us more about where the failure lies.

Last edited by grauerfuchs (2018-09-02 02:31:50)

grauerfuchs · 2018-09-02 02:37:51

@gator96100: That looks like your chip is responding, but I see no further commands beyond the initial enter JTAG mode request is sent to it. Was that the intention, to show what the proper response to the JTAG request looks like?

gator96100 · 2018-09-02 14:23:41

grauerfuchs wrote:

@gator96100: That looks like your chip is responding, but I see no further commands beyond the initial enter JTAG mode request is sent to it. Was that the intention, to show what the proper response to the JTAG request looks like?

It was just to show the response to the JTAG request, to have something to compare it to. I could have send further commands, but I think the is no need to do so.

iceman · 2018-09-02 17:58:48

There was another user NTK who did post about the different proxmark3 devices and the jtag mapping which is different.

http://www.proxmark.org/forum/viewtopic.php?id=4785

spp2000 · 2018-09-03 13:49:00

Hi all,
I have re-checked with a multimeter that TDO of the 6-pin port (PM3 JTAG port) is firmly connected to the TDO pin on the ARM.

There's also continuity between the other pins of the PM3 6-pin port and the respective pins on the ARM chip.

I looked at the TDO pins on both ARM and FPGA: there are no visible traces (except the one from ARM to the 6-pin port), probably they travel under the chips. Anyway there is no continuity between TDO(ARM) and TDO(FPGA), neither from TDOs and GND.

I have checked with the multimeter that there's no short between TDO(J-Link) and its GND.

I have noticed an unpredictable behavior of the TDO line: sometimes (rarely) I see a 'signal' on TDO, most of the time I see no signal at all:

This happens either with TDO(PM3) connected with TDO(J-Link), either with TDO(PM3) disconnected from J-Link (probe on TDO(PM3)), as grauerfhuchs suggested.
The connection of TDO seems to not influence this behavior.
Even with this kind of TDO response, J-Flash reads all 0's.

@iceman: Thanks for the attention, but I'm already using the connections as described by ntk: 3.3V(PM3) connected to Pin_1(J-Link)=VTREF. I needed also to power PM3 with USB, because Pin_1 don't supply power, but is used to detect the power of PM3, as confirmed here in red.
Another connection that I have already tried was to not power PM3 through USB, but connecting 3.3V(PM3) also to Pin_2(J-Link), that in my case provide 3.3V
Both of them power correctly the ARM, as confirmed also by J-Flash: VTarget = 2.998V

Could a failed FW upload cause a damage to the CPU? Or disable JTAG port?

Thank you!

Last edited by spp2000 (2018-09-03 13:50:22)

grauerfuchs · 2018-09-03 14:21:36

It looks from those images like the J-Link is doing exactly what it's supposed to do. It's the ARM chip that's entirely failing to respond to it. Because JTAG is interacting directly with the hardware on a level that doesn't require firmware support (and therefore can be used to upload the firmware when it's newly assembled and blank), it's very unlikely that bad firmware could have caused this. I'm suspecting there's something that's gone wrong with that PM3. If it's still relatively new, you might want to reach out to the seller and see if there's any sort of warranty support or replacement available.

Also, the TDO from the ARM wouldn't go to the TDO of the FPGA; JTAG is serial. If they were chained, one chip would have its TDI connected to the TDO from the other and the outlying pins along with combined TCK and TMS would go back to the interface. Either way, your PM3 simply isn't responding to the request to enter JTAG mode. That's a significant failure.

There are a number of places we could still look (i.e. ARM clock oscillator and power supply to the chip), but this looks to me like a hardware failure that will probably require replacement of one or more components or at least a fair bit of component-level troubleshooting. I'm hoping that someone else on the forums that has more experience with this board and hardware might have some insight or might see something I've missed here.

spp2000 · 2018-09-03 16:36:53

grauerfuchs wrote:

There are a number of places we could still look (i.e. ARM clock oscillator and power supply to the chip), but this looks to me like a hardware failure that will probably require replacement of one or more components or at least a fair bit of component-level troubleshooting. I'm hoping that someone else on the forums that has more experience with this board and hardware might have some insight or might see something I've missed here.

Thank you very much grauerfuchs!
A newbie question: does the ARM require all the surrounding components to estabilish a JTAG connection, or I can just wire VCC, GNC, TCK, TMS, TDI and TDO?
I'm thinking about removing the ARM from the board and testing it with only the 6 JTAG pins connected. Am I crazy?

Last edited by spp2000 (2018-09-03 20:27:52)

grauerfuchs · 2018-09-03 16:40:52

The microcontroller requires some components in order to be functional at all, but the only external connection wires you need are +Vcc (so the JTAG adapter knows what voltages to use), GND, TCK, TMS, TDI, and TDO. Depending on the microcontroller, some also need some form of oscillator circuit and all require the appropriate power on the pins. I haven't built anything from the ground up with this ARM chip, so I'd suggest you refer to the datasheet from the manufacturer to determine the most basic circuit needed to test and run the chip.

spp2000 · 2018-09-03 20:27:25

I read the datasheet. It seems that the minimal connections are:

- VDDIN = VDDFLASH = VDDIO all connected to external supply 3.3V
- VDDOUT(1.8V) = VDDCORE = VDDPLL all toghether, to GND with a decoupling capacitor
- GND
- JTAG (TCK, TMS, TDI and TDO)

Anyway, with my Proxmark connected to USB, I have measured the voltages on all the VDDs listed before and they are all correct! I have also identified the decoupling capacitor.

The ARM should have an internal clock, but I see also an external oscillator 16.000 MHz connected to the ARM (XIN, XOUT). Maybe this is required for RFID HF purposes. Do you agree?

Why do I have a shy ARM??

At this point an ARM replacement will resolve the issue or the failure could be elsewhere?

Last edited by spp2000 (2018-09-03 20:29:33)

spp2000 · 2018-09-03 20:45:14

For your information, this is a schematic of an old Proxmark (with AT91SAM7S64). The informations that I found on the ARM datasheet are coerent with this schematic.
On the top you can see all the VDDs; on the right you can see the JTAG port.

Do you see other things that I should check, that can prevent TDO to talk?

Thanks!!

Last edited by spp2000 (2018-09-03 20:53:50)

grauerfuchs · 2018-09-03 21:18:57

Since we're working with a different CPU and a board that doesn't match the original Proxmark specs, I'm not sure how accurate the old schematics will be for this beyond a general guideline. We know the PM3 Easy is "based" on it, but without running the traces or seeing the actual PM3 Easy schematic, we don't know if any notable changes were made.

As for the processor you do have, it does use an external oscillator as a main clock despite having the ability to generate clocking pulses internally. That means that by the time you're trying to interface with the chip, it's probably relying on a valid clock coming from XIN and XOUT. It would make sense to check the pins and ensure you're getting a valid 16MHz output from the crystal.

The RFID HF clocking would come via the FPGA, since that is handling the actual tag communication. the 16MHz crystal is specifically for the microcontroller.

The next option I can think of is that the NRST pin may be somehow getting held low. If that's the case and the reset controller has asserted, the results of trying to enable JTAG mode appear undefined. I haven't seen anything in the quick review of the datasheet that would indicate how the chip would respond under those conditions. Under normal conditions, it should be reading a digital high.

Despite the NRST being a potential culprit, it might also be of benefit. If you can increase the number of JTAG retries and then short the NRST pin to ground for a few seconds and release it while attempting the JTAG connection, you might get lucky and catch the chip before it can switch over to external clocking or trying to run the problem code entirely.

This brings up the third possibility I see so far, and the above instructions should catch that as well. The ARM chip is capable of disabling the JTAG interface upon request of the running code. If we can force a reset and catch it before it loads that code, you may still be able to get in and re-flash.

spp2000 · 2018-09-04 00:17:14

Thanks grauerfuchs,
I agree that the schematics isn't accurate for me, but I was looking only at JTAG and power supply connections, that in my mind should not differ a lot between the different versions of Proxmark. I cannot find an "easy" schematics.
Me too was thinking about NRST, because I read that it's an optional pin for the JTAG connection..so it can "influence" the connection, but thanks to your knowledge, now I have other tests I can perform!
I will better study the datasheet and NRST on my board, and also look at the external oscillator.
I hope that tomorrow I will have some results.

PS: I forgot to tell you that all the 4 LEDs of my bricked PM3 easy flash every 15 seconds. I don't know if this is important to know or if it's normal for a bricked Proxmark.

grauerfuchs · 2018-09-04 00:21:17

Actually, the information about the LEDs is excellent news. It means it has some form of code, enough that it can launch into either the bootloader or far enough that the watchdog kicks in and forcefully resets.

I ran into that condition when I recently acquired a PM3 easy. The bootloader worked, but it wouldn't take code and it reset after 15-16 seconds. I was able to solve it by using a Linux machine and by holding the button on the PM3 the entire time from connect to completion of firmware load. I'm not sure if Windows will properly see the DFU mode, and you obviously had issues with it before. If you can borrow a Linux machine and then compile and install the official firmware, you might have another and likely easier solution there.

Last edited by grauerfuchs (2018-09-04 00:39:59)

spp2000 · 2018-09-05 00:01:55

Hi grauerfuchs,
with Proxmark connected only to the power supply I don't see oscillations on XIN-XOUT.

Since I mistakenly thought that the button had an effect on resetting the ARM, I followed both the NRST pin and the button trace. This is the schematics:

The NRST pin is always high, because it's always connected to the output of the LDO regulator through a 10k resistor, while the button has effect only on the pin 15 of the ARM.

If I want to manually short NRST to ground to try to catch the chip, should I use a resistor?

Actually I use Windows 7. I remember that before my PM3 was totally bricked (not recognized at all by Windows), few times it was recognized by Windows only if have connected USB with button pressed, so I think that my Windows supports this kind of connection.
Anyway, If I want to test my Proxmark on a Linux machine, where I can find an easy guide to compile and install the official FW? I'm not very familiar with Linux but I have a Kali distro with a persistence partition on a USB key.

Thanks!

grauerfuchs · 2018-09-05 01:16:55

I'm a bit concerned that you don't see the oscillations on the pins. That leads me to believe that the crystal oscillator may have given out. I'll need to run some tests on mine to ensure it's not something we're overlooking, and I'll get back to you on that.

If Windows doesn't recognize it reliably regardless of button press, that makes it more likely that Windows is an issue. Drivers and reliability have often been problematic with Windows.

I recommend following the instructions provided in the official source code wiki https://github.com/Proxmark/proxmark3/wiki/Kali-Linux. They have instructions specifically for Kali. Thankfully, configuration of the environment for the PM3 is quite easy.

If you do want to try directly grounding the NRST pin, I recommend using a 1k resistor between the pin and ground. A 1k resistor is enough to ensure you're not overdriving the circuit if something is holding the pin high, and they're also fairly common, cheap, and easy to acquire.

grauerfuchs · 2018-09-07 01:49:28

I was finally able to get a read from the ARM oscillator. On my PM3 Easy, the oscillator signal was measured at 15.95MHz with a Pk-Pk voltage of 3.88V on the XIN pin. Unfortunately, I cannot provide a picture at this time since the computer interface is not available on the machine I am using. If you do not receive any signal on any of the crystal's four contact pads (2 should have signal), you may very well have a damaged oscillator.

spp2000 · 2018-09-07 18:30:08

Hi grauerfuchs,
I'm writing from Kali now. I have succesfully compiled and installed the FW and the client...but I still have problem connecting the Proxmark: also with the button pressed before USB connection, I can't get Proxmark connected to Linux
.

root@kali:~/proxmark3# dmesg | grep -i usb
[ 4574.912751] usb 1-1: new full-speed USB device number 13 using xhci_hcd
[ 4591.536411] usb 1-1: new full-speed USB device number 14 using xhci_hcd
[ 4608.160539] usb 1-1: new full-speed USB device number 15 using xhci_hcd
[ 4624.784211] usb 1-1: new full-speed USB device number 16 using xhci_hcd
[ 4641.408312] usb 1-1: new full-speed USB device number 17 using xhci_hcd
[ 4658.032210] usb 1-1: new full-speed USB device number 18 using xhci_hcd
[ 4674.659886] usb 1-1: new full-speed USB device number 19 using xhci_hcd
[ 4691.275856] usb 1-1: new full-speed USB device number 20 using xhci_hcd
[ 4707.899875] usb 1-1: new full-speed USB device number 21 using xhci_hcd
[ 4726.147757] usb 1-1: new full-speed USB device number 22 using xhci_hcd
[ 4742.763382] usb 1-1: new full-speed USB device number 23 using xhci_hcd
[ 4759.375537] usb 1-1: new full-speed USB device number 24 using xhci_hcd
[ 4775.999307] usb 1-1: new full-speed USB device number 25 using xhci_hcd
[ 4792.619320] usb 1-1: new full-speed USB device number 26 using xhci_hcd
[ 4809.239210] usb 1-1: new full-speed USB device number 27 using xhci_hcd
[ 4825.859097] usb 1-1: new full-speed USB device number 28 using xhci_hcd
[ 4842.478990] usb 1-1: new full-speed USB device number 29 using xhci_hcd
[ 4859.098661] usb 1-1: new full-speed USB device number 30 using xhci_hcd
[ 4875.718686] usb 1-1: new full-speed USB device number 31 using xhci_hcd
[ 4892.338439] usb 1-1: new full-speed USB device number 32 using xhci_hcd
[ 4908.958549] usb 1-1: new full-speed USB device number 33 using xhci_hcd
[ 4925.574184] usb 1-1: new full-speed USB device number 34 using xhci_hcd
[ 4942.194330] usb 1-1: new full-speed USB device number 35 using xhci_hcd
[ 4958.814213] usb 1-1: new full-speed USB device number 36 using xhci_hcd
...and so on

I have still not tried to ground the NRST pin, but after I read your latest post, my priority is to check again the 16MHz oscillator. It could be the real root cause!
Now I'm going for a walk with my dogs. When I get home, I will go immediately to check the oscillator again!
Thanks!

Last edited by spp2000 (2018-09-07 18:31:28)

grauerfuchs · 2018-09-07 18:41:20

What you're seeing with the reconnects is a known issue with Kali that we have yet to find a proper and permanent solution on, but it may help to follow the tips present at https://github.com/Proxmark/proxmark3/issues/657 for a temporary solution, since that is all we need right now. The good news is that it's seeing the device, which means you should be able to get it working once it stays connected.

spp2000 · 2018-09-07 19:33:00

Thanks grauerfuchs, I killed ModemManager, but in dmesg I continue to see the reconnections because (I suppose) is the Proxmark itself that reboots continuously. I have this situation: the power LED is always on, but every 15-16 secs the other 4 LEDs blink toghether.
I'm going to check the oscillator under the microscope and I will post some pictures and a video of the LEDs (if I find an easy way to share a video)

spp2000 · 2018-09-09 02:02:55

Hi,
I confirm that there isn't any oscillation on the 16MHz, while I can clearly see it on the 13.56MHz (sine wave, about 2.2V pk-pk).

Both of them are 4 pin (3.2x2.5mm).
After following their traces and looking at some datasheets, I have understood that they are different, despite the external appearance being identical: the 13.56MHz should be an Oscillator (VDD, GND, output and tri-state?), whilst the 16 MHz should be a Crystal Unit (2 GND in diagonal). Isn't it?

A crystal unit should be:

whilst an oscillator should be:

Don't blame me if I'm wrong, I'm only trying to understand.

On the 13.56MHz I have 3.28 VDC on the first diagonal and the 13.56MHz wave on the second diagonal.
On the 16MHz I have seen that the first diagonal is all GND and I measure nothing on the second diagonal, or between GND and the pins of that diagonal.

My Proxmark:

I don't know how they work (I'm going to study something about them), but what they need to oscillate? If the 16MHz doesn't oscillates, is it sure it's broken or could it be missing something from the ARM to do its job? In other words, at this point, can we definitely say that the crystal is to be replaced for the Proxmark to work again?

Thanks!

Last edited by spp2000 (2018-09-09 02:11:47)

grauerfuchs · 2018-09-09 09:50:24

The crystal only requires a power source (the ARM chip provides this on the pin), its two capacitors (c6 and c7), and the ground via the capacitors.

If you're not seeing oscillations on the crystal pins 1 and 3, then that means one of the following three things has happened:

1. The ARM chip is not providing enough power to the crystal for it to oscillate.
2. One or both of the capacitors has failed.
3. The crystal has failed.

spp2000 · 2018-09-09 18:03:37

Thanks for the clear explanation! I will do some tests...

spp2000 · 2018-09-18 13:44:59

Well,
the first trial was to replace the 16.000 MHz crystal. I used this: ABM8-16.000MHZ-10-1-U-T

Unfortunately it wasn't the root cause, infact I continued to receive a flat TDO signal from the ARM.

After checking that all the surrounding resistors and capacitors are ok, I finally decided to replace the ARM CPU with a brand new AT91SAM7S512 bought from RS component (to be sure to not receive a counterfeit one).

I removed the old ARM with SRA Fast Chip, that should be equivalent to ChipQuik SMD1NL. It's a low temperature solder + flux, that allows to desolder chip with hundreds of pins with only a solder iron. In 2 minutes I have safely removed the CPU without damaging the chip or the PCB.

In this image you can also see the traces under the chip.

After cleaning the pads, removing all this alloy (important step!), I have soldered the new ARM:

and..... tadaaaaaaaa.... TDO (green signal) is live!!!

So I disconnected the scope-meter, and used J-Link to flash first the recovery image and then the bootload and firmware.

SEGGER J-Link Commander V4.50l ('?' for help)
Compiled Jul  9 2012 15:03:06
DLL version V4.50l, compiled Jul  9 2012 15:02:49
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: 87461523
Feature(s): RDI, FlashBP, FlashDL, JFlash, GDBFull
VTarget = 3.313V
Info: TotalIRLen = 4, IRPrint = 0x01
Found 1 JTAG device, Total IRLen = 4:
 #0 Id: 0x3F0F0F0F, IRLen: 04, IRPrint: 0x1, ARM7TDMI Core
Found ARM with core Id 0x3F0F0F0F (ARM7)
JTAG speed: 100 kHz

Opening data file [D:\official-64-20180917-82258709f6c66a06c4f09dc902128c2d1eb41389\firmware_win\JTAG Only\proxmark3_recovery.bin] ...
 - Data file opened successfully (192492 bytes, 1 range, CRC = 0x252DF2E5)
Connecting ...
 - Connecting via USB to J-Link device 0
 - J-Link firmware: V1.20 (J-Link ARM V8 compiled Nov 28 2014 13:44:46)
 - JTAG speed: 5 kHz (Fixed)
 - Initializing CPU core (Init sequence) ...
    - Initialized successfully
 - JTAG speed: 6000 kHz (Auto)
 - CPU clock frequency: 32 kHz (Auto detected)
 - J-Link found 1 JTAG device. Core ID: 0x3F0F0F0F (ARM7)
 - Connected successfully

Auto programming target (192492 bytes, 1 range) ...
 - Program (0x0 - 0x2EFEB) does not fit into selected flash sectors.
 - Program relocated for programming by 0x100000 bytes
 - Programming target (192492 bytes, 1 range) ...
    - Target programmed successfully
 - Verifying CRC of affected sectors ...
    - CRC of affected sectors verified successfully (CRC = 0xBA8BE661)
 - De-initializing CPU core (Exit sequence) ...
    - De-initialized successfully
 - Target erased, programmed and verified successfully - Completed after 11.131 sec

Opening data file [D:\official-64-20180917-82258709f6c66a06c4f09dc902128c2d1eb41389\firmware_win\JTAG Only\bootrom.bin] ...
 - Data file opened successfully (8192 bytes, 1 range, CRC = 0xC8467158)
Auto programming target (8192 bytes, 1 range) ...
 - Programming target (8192 bytes, 1 range) ...
    - Target programmed successfully
 - Verifying CRC of affected sectors ...
    - CRC of affected sectors verified successfully (CRC = 0x443C732F)
 - De-initializing CPU core (Exit sequence) ...
    - De-initialized successfully
 - Target erased, programmed and verified successfully - Completed after 0.532 sec

Opening data file [D:\official-64-20180917-82258709f6c66a06c4f09dc902128c2d1eb41389\firmware_win\JTAG Only\fullimage.bin] ...
 - Data file opened successfully (184300 bytes, 1 range, CRC = 0xB14E1945)
Auto programming target (184300 bytes, 1 range) ...
 - Programming target (184300 bytes, 1 range) ...
    - Target programmed successfully
 - Verifying CRC of affected sectors ...
    - CRC of affected sectors verified successfully (CRC = 0x401BCE51)
 - De-initializing CPU core (Exit sequence) ...
    - De-initialized successfully
 - Target erased, programmed and verified successfully - Completed after 5.751 sec

Tried the proxmark client and ...IT WORKS!!!

proxmark3> hw version
Prox/RFID mark3 RFID instrument          
bootrom: master/v3.0.1-405-g8225870-suspect 2018-09-17 12:14:57
os: master/v3.0.1-405-g8225870-suspect 2018-09-17 12:14:59
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2018/09/12 at 15:18:46          
uC: AT91SAM7S512 Rev B          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 512K bytes. Used: 192490 bytes (37%). Free: 331798 bytes (63%).          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory 

-----------

proxmark3> hw tune

Measuring antenna characteristics, please wait.........          
# LF antenna: 32.59 V @   125.00 kHz          
# LF antenna: 25.02 V @   134.00 kHz          
# LF optimal: 32.86 V @   123.71 kHz          
# HF antenna: 26.98 V @    13.56 MHz          
Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

-----------

proxmark3> hf 14a info
 UID : 1a 1c 6a 0b           
ATQA : 00 04          
 SAK : 08 [2]          
TYPE : NXP MIFARE CLASSIC 1k | Plus 2k SL1          
proprietary non iso14443-4 card found, RATS not supported          
Chinese magic backdoor commands (GEN 1a) detected          
Prng detection: WEAK

OK OK OK!!!! I'm very happy now!!!

Thanks grauerfuchs and all you that gave me interesting suggestions.
Finally, I can say that in my case the problem was a defective ARM AT91SAM7S512.

I hope that this post, thanks to your suggestions, can become a trobleshooting guide for those with similar problems.

Last edited by spp2000 (2018-09-18 13:47:40)

iceman · 2018-09-18 14:04:14

Great fault finding.
I suggest @OP to edit your first post and add the suffix "[SOLVED]" to your title.

grauerfuchs · 2018-09-18 16:42:52

Fantastic! I'm glad to hear the PM3 is working again!

Tom5ive · 2018-09-19 00:10:42

Oh wow well done well done man !!! This is some nice troubleshooting here!

wiii · 2018-12-25 21:34:20

Your original ARM AT91SAM7S512 was OK, you just need to re-enable JTAG/recover the device via the pin 55 (ERASE).

You can follow the instructions in this note, under 4.9.3;
NOTE

grauerfuchs · 2018-12-25 21:47:10

wiii wrote:

Your original ARM AT91SAM7S512 was OK, you just need to re-enable JTAG/recover the device via the pin 55 (ERASE).

Interesting thought. I hadn't reviewed this particular chip in enough depth to find that little nugget. It certainly would be a step worth trying the next time we run into a corrupted and unresponsive device.

cosmo61 · 2019-04-04 20:12:28

wiii wrote:

Your original ARM AT91SAM7S512 was OK, you just need to re-enable JTAG/recover the device via the pin 55 (ERASE).
You can follow the instructions in this note, under 4.9.3;
NOTE

Thank's you saved my day. I bricked my device after a couple of hour.

I got the same problem as described in this thread
My jtag on the proxmark esay was locked, and when i did a usb elf update it broke the bootloader.

After i did the pin 55 (ERASE), everything went back to normal.

Proxmark3 community

Announcement

#1 2018-08-29 21:10:02

[solved] Help for a bricked PM3 Easy

#2 2018-08-30 02:28:16

Re: [solved] Help for a bricked PM3 Easy

#3 2018-08-30 08:04:10

Re: [solved] Help for a bricked PM3 Easy

#4 2018-08-30 17:07:08

Re: [solved] Help for a bricked PM3 Easy

#5 2018-08-30 17:37:12

Re: [solved] Help for a bricked PM3 Easy

#6 2018-08-30 21:40:28

Re: [solved] Help for a bricked PM3 Easy

#7 2018-08-30 22:40:58

Re: [solved] Help for a bricked PM3 Easy

#8 2018-08-30 23:48:42

Re: [solved] Help for a bricked PM3 Easy

#9 2018-08-31 00:19:46

Re: [solved] Help for a bricked PM3 Easy

#10 2018-08-31 11:00:27

Re: [solved] Help for a bricked PM3 Easy

#11 2018-08-31 20:55:12

Re: [solved] Help for a bricked PM3 Easy

#12 2018-08-31 21:59:16

Re: [solved] Help for a bricked PM3 Easy

#13 2018-09-02 01:14:41

Re: [solved] Help for a bricked PM3 Easy

#14 2018-09-02 02:20:27

Re: [solved] Help for a bricked PM3 Easy

#15 2018-09-02 02:31:00

Re: [solved] Help for a bricked PM3 Easy

#16 2018-09-02 02:37:51

Re: [solved] Help for a bricked PM3 Easy

#17 2018-09-02 14:23:41

Re: [solved] Help for a bricked PM3 Easy

#18 2018-09-02 17:58:48

Re: [solved] Help for a bricked PM3 Easy

#19 2018-09-03 13:49:00

Re: [solved] Help for a bricked PM3 Easy

#20 2018-09-03 14:21:36

Re: [solved] Help for a bricked PM3 Easy

#21 2018-09-03 16:36:53

Re: [solved] Help for a bricked PM3 Easy

#22 2018-09-03 16:40:52

Re: [solved] Help for a bricked PM3 Easy

#23 2018-09-03 20:27:25

Re: [solved] Help for a bricked PM3 Easy

#24 2018-09-03 20:45:14

Re: [solved] Help for a bricked PM3 Easy

#25 2018-09-03 21:18:57

Re: [solved] Help for a bricked PM3 Easy

#26 2018-09-04 00:17:14

Re: [solved] Help for a bricked PM3 Easy

#27 2018-09-04 00:21:17

Re: [solved] Help for a bricked PM3 Easy

#28 2018-09-05 00:01:55

Re: [solved] Help for a bricked PM3 Easy

#29 2018-09-05 01:16:55

Re: [solved] Help for a bricked PM3 Easy

#30 2018-09-07 01:49:28

Re: [solved] Help for a bricked PM3 Easy

#31 2018-09-07 18:30:08

Re: [solved] Help for a bricked PM3 Easy

#32 2018-09-07 18:41:20

Re: [solved] Help for a bricked PM3 Easy

#33 2018-09-07 19:33:00

Re: [solved] Help for a bricked PM3 Easy

#34 2018-09-09 02:02:55

Re: [solved] Help for a bricked PM3 Easy

#35 2018-09-09 09:50:24

Re: [solved] Help for a bricked PM3 Easy

#36 2018-09-09 18:03:37

Re: [solved] Help for a bricked PM3 Easy

#37 2018-09-18 13:44:59

Re: [solved] Help for a bricked PM3 Easy

#38 2018-09-18 14:04:14

Re: [solved] Help for a bricked PM3 Easy

#39 2018-09-18 16:42:52

Re: [solved] Help for a bricked PM3 Easy