Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Initially tried to upgrade the firmware on the Proxmark but bricked it and is no longer recognized by the OS so I'm trying to unbrick it.
Following https://github.com/Proxmark/proxmark3/wiki/Debricking-Proxmark3-with-buspirate to try and unbrick a PM3 Easy.
I have upgraded the BusPirate firmware to v6.1 with bootloader v4.4.
Compiled OpenOCD with BusPirate support.
Downloaded proxmark from github, and ran
make clean && make allConnecting to the chip, it looks like it recognizes the device ID correctly, but from then on it only reads zeroes.
./openocd -f at91sam7s512-buspirate.cfg
Open On-Chip Debugger 0.10.0+dev-00621-g334552bc (2018-12-17-18:24)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
srst_only srst_pulls_trst srst_gates_jtag srst_open_drain connect_deassert_srst
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Buspirate JTAG Interface ready!
Info : This adapter doesn't support configurable speed
Info : JTAG tap: sam7x.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787 (<unknown>), part: 0xf0f0, ver: 0x3)
Info : TAP auto0.tap does not have IDCODE
Info : TAP auto1.tap does not have IDCODE
Info : TAP auto2.tap does not have IDCODE
Info : TAP auto3.tap does not have IDCODE
Info : TAP auto4.tap does not have IDCODE
Info : TAP auto5.tap does not have IDCODE
Info : TAP auto6.tap does not have IDCODE
Info : TAP auto7.tap does not have IDCODE
Info : TAP auto8.tap does not have IDCODE
Info : TAP auto9.tap does not have IDCODE
Info : TAP auto10.tap does not have IDCODE
Info : TAP auto11.tap does not have IDCODE
Info : TAP auto12.tap does not have IDCODE
Info : TAP auto13.tap does not have IDCODE
Info : TAP auto14.tap does not have IDCODE
Info : TAP auto15.tap does not have IDCODE
Info : TAP auto16.tap does not have IDCODE
Info : TAP auto17.tap does not have IDCODE
Info : TAP auto18.tap does not have IDCODE
Info : TAP auto19.tap does not have IDCODE
Warn : Unexpected idcode after end of chain: 52 0x00000000
Warn : Unexpected idcode after end of chain: 84 0x00000000
Warn : Unexpected idcode after end of chain: 116 0x00000000
Warn : Unexpected idcode after end of chain: 148 0x00000000
Warn : Unexpected idcode after end of chain: 180 0x00000000
Warn : Unexpected idcode after end of chain: 212 0x00000000
Warn : Unexpected idcode after end of chain: 244 0x00000000
Warn : Unexpected idcode after end of chain: 276 0x00000000
Warn : Unexpected idcode after end of chain: 308 0x00000000
Warn : Unexpected idcode after end of chain: 340 0x00000000
Warn : Unexpected idcode after end of chain: 372 0x00000000
Warn : Unexpected idcode after end of chain: 404 0x00000000
Warn : Unexpected idcode after end of chain: 436 0x00000000
Warn : Unexpected idcode after end of chain: 468 0x00000000
Warn : Unexpected idcode after end of chain: 500 0x00000000
Warn : Unexpected idcode after end of chain: 532 0x00000000
Warn : Unexpected idcode after end of chain: 564 0x00000000
Warn : Unexpected idcode after end of chain: 596 0x00000000
Warn : Unexpected idcode after end of chain: 628 0x00000000
Error: double-check your JTAG setup (interface, speed, ...)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000000"
Error: auto0.tap: IR capture error; saw 0x0000 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 0
Error: unknown EmbeddedICE version (comms ctrl: 0x00000000)
Info : sam7x.cpu: hardware has 2 breakpoint/watchpoint units
Info : Listening on port 3333 for gdb connections
Info : accepting 'telnet' connection on tcp/4444Now when I try to halt, I am never able to:
> halt
Halt timed out, wake up GDB.
timed out while waiting for target haltedWhen I check the banks, they are 0 in size, which doesn't seem right.
> flash banks
#0 : sam7x512.flash.0 (at91sam7) at 0x00000000, size 0x00000000, buswidth 0, chipwidth 0
#1 : sam7x512.flash.1 (at91sam7) at 0x00000000, size 0x00000000, buswidth 0, chipwidth 0I am confident my wiring is correct and have checked it many times. I've also gone over this same process on another computer and distribution (have tried Linux Mint and Kali Linux).
Any suggestions on what next to troubleshoot?
Last edited by poxmarkfree (2019-01-01 13:02:41)
Offline
Are you using a buspirate 3.x or the newer 4.x one?
Did you already tried another firmware version of the buspirate?
You could test one of the community builds here: https://github.com/mikebdp2/Bus_Pirate/tree/master/package_latest/BPv3 assuming you have a BPv3.x
- 0 - Do not optimize. The compiler’s goal is to reduce the cost of compilation and to make debugging produce the expected results
- 1 - Optimize. Optimizing compilation takes somewhat longer, and a lot more host memory for a large function. The compiler tries to reduce code size and execution time
- 2 - Optimize even more. The compiler performs nearly all supported optimizations that do not involve a space-speed trade-off
- s - Optimize yet more favoring size (superset of O2)
- 3 - Optimize yet more favoring speed (superset of O2)
you can find some more builds in this thread: http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=15#p65313
//edit: do you have a proxmark with at91sam7s512 or the smaller xxx256?
Last edited by Mackwa (2018-12-25 18:21:54)
Offline
I'm using the BusPirate 3. To rule out the BusPirate 3 being the problem, I just tried with a J-link Segger and I get the same issue.
It seems like the TDI pin is not working. I get the same console output if I unplug the TDI pin.
I've also checked that the TDI pin coming out from the JTAG connection runs to the chip in the expected spot, so could it be that the problem lies with the chip?
I'm using at91sam7s512.
cat /etc/udev/rules.d/60-jlink.rules
ATTRS{idVendor}=="1366", ATTRS{idProduct}=="0101", MODE="664", GROUP="plugdev"cat at91sam7s512-jlink.cfg
telnet_port 4444
gdb_port 3333
interface jlink
transport select jtag
adapter_khz 1000
reset_config srst_only srst_pulls_trst
jtag newtap sam7x cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x3f0f0f0f
target create sam7x.cpu arm7tdmi -endian little -chain-position sam7x.cpu
sam7x.cpu configure -event reset-init {
soft_reset_halt
mww 0xfffffd00 0xa5000004 # RSTC_CR: Reset peripherals
mww 0xfffffd44 0x00008000 # WDT_MR: disable watchdog
mww 0xfffffd08 0xa5000001 # RSTC_MR enable user reset
mww 0xfffffc20 0x00005001 # CKGR_MOR : enable the main oscillator
sleep 10
mww 0xfffffc2c 0x000b1c02 # CKGR_PLLR: 16MHz * 12/2 = 96MHz
sleep 10
mww 0xfffffc30 0x00000007 # PMC_MCKR : MCK = PLL / 2 = 48 MHz
sleep 10
mww 0xffffff60 0x00480100 # MC_FMR: flash mode (FWS=1,FMCN=72)
sleep 100
}
gdb_memory_map enable
sam7x.cpu configure -work-area-virt 0 -work-area-phys 0x00200000 -work-area-size 0x10000 -work-area-backup 0
flash bank sam7x.flash.0 at91sam7 0 0 0 0 sam7x.cpu 0 0 0 0 0 0 0 18432
flash bank sam7x.flash.1 at91sam7 0 0 0 0 sam7x.cpu 1 0 0 0 0 0 0 18432Offline
This is starting to look eerily similar to a recent issue with another PM3 Easy. Since the chip isn't responding at all, I suggest trying a trick recently posted in that thread (here). Try tying the at91sam7s512 chip's pin 55 to +3.3v for a half second or more while it's powered up. According to the document linked in that thread, raising this pin is supposed to trigger the chip to erase all programming and re-enable the JTAG interface.
Offline
Thanks so much grauerfuchs!
I had read that thread before but stopped after the OP marked it as [SOLVED] after replacing the chip because I assumed it turned out to be faulty hardware.
All good now, cheers!
Offline
Excellent. That particular trick wasn't made apparent until well after the chip had been replaced. I'm glad we were able to save you the trouble of replacing the chip.
If the PM3 is working properly once more, please also change the title on the first post and mark the thread as [SOLVED].
Offline