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.
I will continue to try. when we will all together decide that it's time for me to stop tring the repair, we can divide the cost of these 2 broken boards and 2 person can get back the money and the other guys can receive their working board. It's 180€ divided by 20.
Sounds fair, payment-wise. However, it's up to you to decide when it's time to stop trying. It's your time (well, also enio and vivat), so you decide when you've had enough of it.
Offline
If "GauchoMP3" will be good *and i am sure it will!) i re-suggest you to make a kickstarter campaign for it. If the campaign will be good too you can collect money to develop an improved version with the help of the forum's users (ex. with uhf support). If you want to know more about kickstarter i can answer your questions.
Offline
I also advocate kickstarter. However, I think it's wise to do most of the prototyping first. Kickstarter is basically just a tool to get fully paid pre-orders and reach a wide audience.
Offline
gaucho
Don't give up! We will fix that 2 boards. Remember, we have already fixed 18 boards from 20!
I like the enclosure from proxmark3.com. Also Adam Laurie's 9 EUR case seems to be nice.
Last edited by vivat (2014-04-07 07:07:06)
Offline
Board1:
let's give a percentage of probability of broken arm vs fpga.
Then i'll change one of the 2 components.
now i don't have an arm, i should find one locally since i don't want to pay the 30€ for the shipment.
And, if not needed, i don't want to lost my 8€ fpga cause i want to use it on my new future board.
EDIT: watching this post: http://www.proxmark.org/forum/viewtopic … 623#p10623
i say 80%arm and 20%fpga
On board 2 I replaced C35 and C14. it still don't work. I'm sure i can save this board. I don't remembet what other components i replaced on this board..
Last edited by gaucho (2014-04-07 10:22:36)
Offline
I can't find local reseller for the arm. the less cost, ordering the 256K version on ebay is 10€ and it takes 1 month: http://www.ebay.it/itm/1-Piece-Atmel-AT91SAM7S256AU-AT91SAM7S256-AU-TQFP64-IC-Chip-/400620919313?pt=LH_DefaultDomain_0&hash=item5d46de1a11
i can try to unsolder it from a working board and then resolder it on the broken board. sincerely i would prefer to stop trying the repair.
Last edited by gaucho (2014-04-07 10:42:30)
Offline
let's analyze better the situation,
i wrote few posts above that:
board1: on lf read command the board stops and resets after a while and on the SSP_DOUT there is no signal, but on the HF 14A READ command the board does not stops, and the SSP_DOUT moves....
....vivat said that this signal is generated by the ARM.....
this have sense if the SSP_DOUT section of the arm is damaged.. or if the DIN line recever of the arm is damaged.. correct?
Offline
You are ignoring what I already wrote.
Sniff the SSC bus with your logic analyzer. If you don't see the difference between working and non-working board, I think FPGA&ARM are OK.
Then test relay/mux
1. hw setmux lopkd
2. check with multimeter continuity test between relay pin 4(lo-pkd)
3. repeat for other 3 modes
Offline
Any result with the debugprints in holimans fullimage yet?
Offline
i flashed holiman FW.
i get these logs:
proxmark3> hw ver
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 842
#db# os: master/v1.0.0-3-gcba867f-dirty-suspect 2014-04-04 19:46:06
#db# FPGA image built on 2014/03/24 at 21:54:44
uC: AT91SAM7S512 Rev A
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 512K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3> lf ti read
#db# A
#db# B
#db# C
#db# D
#db# E
#db# F
#db# G
#db# H
#db# J
proxmark3>
the board did not crash but the red led stay ON.
EDIT: according to holiman code, AT91C_SSC_RXRDY is equal to FALSE on the broken board. what is it? serial rx ready? when is it switched to TRUE?
As a reference, i report holiman debug code :
void testLFHidLowlevelOperations()
{
DbpString("A");
FpgaSendCommand(FPGA_CMD_SET_DIVISOR, 95); //125Khz
DbpString("B");
FpgaWriteConfWord(FPGA_MAJOR_MODE_LF_READER);
DbpString("C");
// Connect the A/D to the peak-detected low-frequency path.
SetAdcMuxFor(GPIO_MUXSEL_LOPKD);
DbpString("D");
// Give it a bit of time for the resonant antenna to settle.
SpinDelay(50);
DbpString("E");
// Now set up the SSC to get the ADC samples that are now streaming at us.
FpgaSetupSsc();
DbpString("F");
if (AT91C_BASE_SSC->SSC_SR & AT91C_SSC_TXRDY) {
DbpString("G");
AT91C_BASE_SSC->SSC_THR = 0x43;
LED_D_ON();
}
DbpString("H");
if (AT91C_BASE_SSC->SSC_SR & AT91C_SSC_RXRDY) {
DbpString("I");
dest[i] = (uint8_t)AT91C_BASE_SSC->SSC_RHR;
i++;
LED_D_OFF();
}
DbpString("J");
}
void ReadTItag(void)
{
testLFHidLowlevelOperations();
}
Last edited by gaucho (2014-04-08 10:27:43)
Offline
update: some of you wrote to me a private email telling that they agree to add 10€ and to stop tries.
BUT the question is : who agree to get back its money (90€+4%) ? we need at least 2 person that accept to do it. I can be one of the 2, if needed.
anyway i found a method to get a free 512k ARM, but i need at least one month.
Offline
Hi Gaucho
While I very much enjoyed following your journey, and I lso very much like to have another Proxmark3, I agree to be one of those two that will not get it. Maybe when you go with the cheaper version, I can try again :-)
But I also ordered some cards from you. Can you still send them to me?
Cheers
Michael
Offline
Ah darn - i only see now that this function doest check RXREADY in a while loop. we need a while loop dbprinting status register, and if it sees rxready dbprint content of RHR- ill prepare you a fullimage when i find time.
Offline
Ah darn - i only see now that this function doest check RXREADY in a while loop. we need a while loop dbprinting status register, and if it sees rxready dbprint content of RHR- ill prepare you a fullimage when i find time.
could you give me some more explanation about this signal? when is it fired?
Offline
Dear all,
today i replaced on Board2 the C15 and D10.
Now board 2 works perfectly. so, it was D10, since if i well remember i still changed in the past on this board the C15.
We have only one board not working.
Offline
By means of the holiman debug fw and a oscilloscope i think that we can find a method to be sure at 100% which is the broken chip.
@vivat: i'm not ignoring you, it's just that i'm not confident with logic state analyzer, and the board has no ready tests points to attach the state analyzer probes and i don't have it in my main lab.
about the mux: it is setted by the arm, it has nothing to do with the board crash, as you can see from the log obtained with holiman debug FW.
Offline
RXREADY is just a bitmask you AND with RX status register SSC_SR to see if a new dataframe (here 8 bit) has arrived and is ready to be read from rx receive hold register SSC_RHR.
So we want something like while ( ;; ) { If (ssc_sr && rxready) { dbprintf("%d\n", (uint8)ssc_rhr)); } }
It will tell us if something arrives on ssc, and if - what arrives.
Offline
RXREADY is just a bitmask you AND with RX status register SSC_SR to see if a new dataframe (here 8 bit) has arrived and is ready to be read from rx receive hold register SSC_RHR.
So we want something like while ( ;; ) { If (ssc_sr && rxready) { dbprintf("%d\n", (uint8)ssc_rhr)); } }
It will tell us if something arrives on ssc, and if - what arrives.
why in the holiman code there is only a single & ? is it a bitwise AND? or a logic AND ?
i understood from your message that "&" is a bitwise operator and RXREADY is a CONSTANT.
is it correct?
So the arm is not receiving data from the DIN ?
could someone provide the compiled code suggested by Enio (with single & i suppose) in order to check what we receive on the serial link? then i could compare this log with what i see on the oscilloscope. And if on the scope i will see bits moving, and nothing displayed on the log, we will know that the ARM has problems.
p.s.:what about the time needed to send the ascii characters on the terminal window ? will it take too much time to follow data coming from the serial line?
Last edited by gaucho (2014-04-08 17:41:00)
Offline
Enio wrote:RXREADY is just a bitmask you AND with RX status register SSC_SR to see if a new dataframe (here 8 bit) has arrived and is ready to be read from rx receive hold register SSC_RHR.
So we want something like while ( ;; ) { If (ssc_sr && rxready) { dbprintf("%d\n", (uint8)ssc_rhr)); } }
It will tell us if something arrives on ssc, and if - what arrives.
why in the holiman code there is only a single & ? is it a bitwise AND? or a logic AND ?
i understood from your message that "&" is a bitwise operator and RXREADY is a CONSTANT.
is it correct?So the arm is not receiving data from the DIN ?
could someone provide the compiled code suggested by Enio (with single & i suppose) in order to check what we receive on the serial link? then i could compare this log with what i see on the oscilloscope. And if on the scope i will see bits moving, and nothing displayed on the log, we will know that the ARM has problems.
p.s.:what about the time needed to send the ascii characters on the terminal window ? will it take too much time to follow data coming from the serial line?
Yes, sorry, ofcourse the Bitwise "&". I will do it right now. Time needed can indeed lead to loss on data, but for this check it shouldnt matter. If we only read evry 10th we should still see if the data makes sense (im 99% sure we dont get any data on ssc leading to your resets, this test should give a clear answer there.).
Edit: Sorry for the delay - my version is messed up a bit due to various tests - you can only use lf read. https://www.dropbox.com/s/kcu9sbv25s3i7 … limage.elf
In case you measure - If you wonder about pck0 frequency - I changed it to be PLL / 2, that is 48MHz. SSC is still clocked on 24 MHz. SSC FRAME is different on lf read - its gated with the antenna signal, so im not sure about its frequency.
Just some dirty quick changes in DoAcquisition125k function. If it doesnt print any samples and resets, theres something really wrong with the ssc connection.
// split into two routines so we can avoid timing issues after sending commands //
void DoAcquisition125k(void)
{
uint8_t *dest = (uint8_t *)BigBuf;
int n = sizeof(BigBuf);
int i;
Dbprintf("Listening to SSC now.."); // Gauchotest
memset(dest, 0, n);
i = 0;
for(;;) {
// Useless burn of cpupower commented out.
/* if (AT91C_BASE_SSC->SSC_SR & AT91C_SSC_TXRDY) {
AT91C_BASE_SSC->SSC_THR = 0x43;
Dbprintf("TXREADY, sending 0x43 for no real reason.");// Gauchotest
// LED_D_ON();
} */
if (AT91C_BASE_SSC->SSC_SR & AT91C_SSC_RXRDY) {
dest[i] = (uint8_t)AT91C_BASE_SSC->SSC_RHR;
Dbprintf("RXREADY, we got data: %d Bufferindex is: %d",(uint8_t)AT91C_BASE_SSC->SSC_RHR, i); // Gauchotest
i++;
// LED_D_OFF();
if (i >= 5000) break;//>= n) break; // Gauchotest
}
}
Dbprintf("buffer samples: %02x %02x %02x %02x %02x %02x %02x %02x ...",
dest[0], dest[1], dest[2], dest[3], dest[4], dest[5], dest[6], dest[7]);
}
If you need assistance - ill be on for a bit in IRC (check my signature). Just Mention my nickname (Enio) and itll beep to me.
Last edited by Enio (2014-04-08 19:38:56)
Offline
this is the result:
proxmark3> hw tune
#db# Measuring antenna characteristics, please wait...
#db# Measuring complete, sending report back to host
# LF antenna: 21.89 V @ 125.00 kHz
# LF antenna: 22.29 V @ 134.00 kHz
# LF optimal: 25.11 V @ 129.03 kHz
# HF antenna: 0.06 V @ 13.56 MHz
# Your HF antenna is unusable.
proxmark3> lf read
#db# Listening to SSC now..
Waiting for a response from the proxmark...
Don't forget to cancel its operation first by pressing on the button
then it resets..
are you sure that in this fw version the commands are sent to fpga?
why did you commented the section
/* if (AT91C_BASE_SSC->SSC_SR & AT91C_SSC_TXRDY) {
AT91C_BASE_SSC->SSC_THR = 0x43;
Dbprintf("TXREADY, sending 0x43 for no real reason.");// Gauchotest
// LED_D_ON();
} */
if you confirm that your test FW is working correctly i go to do some measures on the scope.
I'll wait your feedback.
Last edited by gaucho (2014-04-09 09:34:17)
Offline
Update: i purchased an arm and i will receive it within wednesday (not today of course!!).
Last edited by gaucho (2014-04-09 11:03:58)
Offline
I tested this fw on mine, it works. So its certain that we dont get the RXREADY bit set in arm. And hf worked on that board before? If yes it must be related to the clock source used for ssc stuff. And that is just pck0. Ssc is also gated with the antenna signal ant_lo (producing the field) but ant_lo is derived off pck0 too. Ill think how we can debug what happens there, measurments on ssc probably just show no signal.
Ill think about a solution.
The TX stuff is just about sending on ssc to fpga - its not used in lf read.
Can you confirm HF worked on that board? (Not with my FW)
Last edited by Enio (2014-04-09 16:17:38)
Offline
read again my post please: http://www.proxmark.org/forum/viewtopic … 623#p10623
there is no problem in pck0.
this board worked on hf but not on lf and now it stops on both paths.
this means, in my opinion that there is a broken serial line on the arm.
Tomorrow i will show to you that all signals are present on arm pins, but it can't receive anything.
Offline
There might still be an issue with fpga not getting pck0 routed INSIDE. We ll have to see.
Offline
yes but, did you read my post? SPCK , SSP_CLK, and ADC_CLK are ok. moreover if i will see the gate (frame), the clock, and the data (DIN) moving, and nothing is received on the client (using your code) i think that we can say that the arm is broken. correct?
Offline
i did the following measure:
with enio firmware (i hope that you double checked it and i hope that you are sure that it works as expected by logging any received byte on the serial line) i soldered wires on ARM pins and i connected to the oscilloscope.
during lf command (until board reset) i can see periodic frames, continuous clock, a lot of moving bits on the DIN but no DOUT(even if it moved from first trigger showed on the first image and one of the next triggers shown on the second image).
Could someone confirm that the data sent from the fpga to the arm is received on arm pin 10 (SSP_DIN) ????
If this is true, it's confirmed that the arm is broken, since i don't receive anything on the modified enio fw. do you agree??
notes: the oscilloscope probe on channel 1 is divided by 10 (so this is the reason why its scale is different).
channel 1 is the frame (arm pin 20)
channel 2 is the clock (arm pin 19)
channel 3 is the DOUT (arm pin 9)
channel 4 is the DIN (arm pin 10)
trigger is on channel 1 (frame)
These are 2 screenshots taken during the lf read command, as you can see frame and clock are constant and the DIN pin is moving.
any consideration?
EDIT: another consideration: it's clear to me that the signal is read on the negative edge of the clock, so in the first screenshot the arm should have received 10000010 (82 hex, 130 dec) and in the second screenshot should have received 01110110 (76hex, 118dec)
Last edited by gaucho (2014-04-10 13:32:43)
Offline
Hmm this is odd. I need to check the code. Normally the frame goes high together with the first bit on line and is low for the next 7. What might be bad is that on lf read, due to being gated with antenna signal, you have pauses where no data is put on ssc - i need to check that again though when i get home.
Offline
I am one of the group buy (the italian one), i think that you have already done more that anyone could request. So i just want to say that for me is ok to pay my part of the no working boards, you can give up whenever you want.
Thank you for your awesome work anyway.
Offline
Hmm this is odd. I need to check the code. Normally the frame goes high together with the first bit on line and is low for the next 7.
the frame is a gate where the arm is informed that it must start aquiring data.
Data is read by the arm each clock cycle inside the gate. This is standard to many serial lines, I think you're wrong.
What might be bad is that on lf read, due to being gated with antenna signal, you have pauses where no data is put on ssc - i need to check that again though when i get home.
if you print whatever arrives to the serial line, and if the DIN is the ARM input and not the output, there is no doubt about the situation.
Offline
I am one of the group buy (the italian one), i think that you have already done more that anyone could request. So i just want to say that for me is ok to pay my part of the no working boards, you can give up whenever you want.
Thank you for your awesome work anyway.
thank you but i got it. Wednesday i'll replace the arm and i'll solve the problem.
i think i can send boards Within saturday.
Offline
betelgeuse wrote:I am one of the group buy (the italian one), i think that you have already done more that anyone could request. So i just want to say that for me is ok to pay my part of the no working boards, you can give up whenever you want.
Thank you for your awesome work anyway.thank you but i got it. Wednesday i'll replace the arm and i'll solve the problem.
i think i can send boards Within saturday.
Great
Offline
Enio wrote:Hmm this is odd. I need to check the code. Normally the frame goes high together with the first bit on line and is low for the next 7.
the frame is a gate where the arm is informed that it must start aquiring data.
Data is read by the arm each clock cycle inside the gate. This is standard to many serial lines, I think you're wrong.Enio wrote:What might be bad is that on lf read, due to being gated with antenna signal, you have pauses where no data is put on ssc - i need to check that again though when i get home.
if you print whatever arrives to the serial line, and if the DIN is the ARM input and not the output, there is no doubt about the situation.
The following explains that the data is put on ssp_din on FPGA PIN 32
Excerpt of lo_read.v:
// serialized SSP data is gated by ant_lo to suppress unwanted signal
assign ssp_din = to_arm_shiftreg[7] && !ant_lo;
Excerpt of fpga.ucf:
NET "ssp_din" LOC = "P32" ;
Checking the eagle file we see that ssp_din pin of FPGA indeed is connected to PIN10 on ARM.
Lets check the Frame thing:
I also checked the ARM docs again (Figure 32-11. Receive Pulse/Edge Start Modes) explains the different modes we have.
Excerpt of fpgaloader.c in armsrc:
// 8 bits per transfer, no loopback, MSB first, 1 transfer per sync
// pulse, no output sync, start on positive-going edge of sync
AT91C_BASE_SSC->SSC_RFMR = SSC_FRAME_MODE_BITS_IN_WORD(8) | AT91C_SSC_MSBF | SSC_FRAME_MODE_WORDS_PER_TRANSFER(0);
We are both right, it actually doesnt matter. "start on positive-going edge of sync" doesnt care if we stay High the whole transfer or just the first bit. In lf_read.v it seems it stays high for the full duration of the transmission. The code is overly complicated though, but it works.
Anyways, it seems we get data on SSC (I read 1000010 on first screen too) thus FPGA seems to work and something is wrong on ARM. When you are absolutely sure that the pin is correctly soldered it can only be ARM. Or could we have a bad voltage on SSC tricking us to think all is fine from FPGA? Probably not.
Offline
voltages of these signals on the broken board are the same of working board: 3Volt
I-m sure 100% that the solderings are ok.
Compliments to us all for the analysis.
I'll let you know when i'll receive the arm.
Offline
I received the arm.
I also soldered it: I'm becoming a master at making the welds
I have the JTAG programmer at home, not here.
So I'm tring to understand how to flash it directly with usb.
I found the datasheet on atmel website: http://www.atmel.com/Images/doc6175.pdf
and on other forums i read that, if i well understood, it is possible to use the rom flash of the arm in order to avoid the need of a jtag programmer. All can be done from usb.
Do to this, you need to short to Vcc the pins: TST (40), PA0 (48), PA1 (47) and PA2(44) for at least 10 seconds.
Could someone confirm this? It could be a really nice alternative to the jtag connector, on a future board.
EDIT: what do you understand at page 25 of the linked document? i understood that i can flash the arm with the usb. correct?
The cristal should be 18.432 MHz..our crystal is 16MHz. does it means that it will not work or i misunderstood?
8.10 SAM-BA Boot Assistant
The SAM-BA® Boot Recovery restores the SAM-BA Boot in the first two sectors of the on-chip Flash memory. The
SAM-BA Boot recovery is performed when the TST pin and the PA0, PA1 and PA2 pins are all tied high for 10 seconds.
Then, a power cycle of the board is mandatory.
The SAM-BA Boot Assistant is a default Boot Program that provides an easy way to program in situ the on-chip Flash
memory.
The SAM-BA Boot Assistant supports serial communication through the DBGU or through the USB Device Port. (The
SAM7S32/16 have no USB Device Port.)
? Communication through the DBGU supports a wide range of crystals from 3 to 20 MHz via software autodetection.
? Communication through the USB Device Port is limited to an 18.432 MHz crystal. (
The SAM-BA Boot provides an interface with SAM-BA Graphic User Interface (GUI).
Last edited by gaucho (2014-04-14 14:01:03)
Offline
Hmm i guess it wont work with our crystal then..
Offline
yesterday i flashed the FW with the jtag, today i tested with all commands and antennas: BOARD REPAIRED
This is the plan: today i give the boards to a collegue to full wash with solvent cause most of the repaired boaqrds were not washed after repair and the flux after some time will start to conduct and it may cause problems, so it is better to wash them.
this afternoon i will start to write addresses on the parcels.
Last edited by gaucho (2014-04-15 07:02:08)
Offline
Good news!
Offline
Fantastic work, all of you!
Offline
Thats really cool Congratulations.
Offline
after washing i re-tested them all.
Then i start preparing the parcels.
I re-tested all the boards.
I packed only the half of the boards (with accessories).
Tomorrow i'll continue.
Note: I found only 2 boards that i need to recheck: pressing the button it never stops the recursive command "lf hid fskdemod".
Tomorrow I will first try to reflash with latest FW (i'm not sure which version is on, since some board were with the Enio modified debug FW)
anyway all the commands works fine on these boards, so it is a minor problem.
Offline
I started to send the boards in the order i received the money, so i sent to:
Neuer User, roel, holiman, Kilae, Akwarelista, Tariq.
on the parcels i wrote "not working parts - to be repaired" just to avoid the customs (in some cases were not needed but i was in hurry and i wrote it on all the boards), so NO FEAR, boards are ok.
I will send to you private email with the tracking number of the shipment.
Please when you receive do these steps in order:
1)test it and check that it works.
2)post here your thanks
3)flash latest FW revision cause some board has a test firmware version.
i will write here detailed info for newbye about steps to follow.
NOTE: if you ordered also other items they are included in your parcel, so don't bother me if it is not needed.
Last edited by gaucho (2014-04-15 17:29:21)
Offline
the problem on the button was easy to solve: the button was unsoldered.
Offline
prepared all the parcels
sent the parcels to Res,Benoit,ikarus and twixx
I miss only betelgeuse and new_user13 . I sent them private mail.
Coming back from the post office i was thinking that a PM3 with the bluetooth will be easyer to integrate with the smartphone.
But may be it saves nothing on client coding.
Offline
sent parcel to betelgeuse
i'm waiting new_user13 reply before to proceed with the shipment. i miss its customs quota.
i completed my work. if someone did not receive my private email with the tracking number, contact me.
Offline
man i just saw this thread, would have been super useful to read it through a month ago ! some good info though, unfortunately i found the thread by googling the things we'd found out .
oh well
Offline
if you're interested on a cheap board, post a message on this thread http://www.proxmark.org/forum/viewtopic … 960#p10960
and subscribe to it.
If we will organize new group buy or we will start production of new cheap board, i will inform you with a message on that thread.
Last edited by gaucho (2014-04-23 10:13:44)
Offline
Package received here too.
Gaucho: Thank you very much. Outstanding work and committment!
Offline
Package recieved.
Quick test:
* Crack mifare classic tag [done]
* Read the UID of a lf tag [done]
Thank you sooo much for all the effort you put into these proxmarks!
The list of issues you encountered and fixed(!) is quite impressive!
And of course: thx to all the community members how helped him!
Last edited by ikarus (2014-05-05 21:42:19)
Offline
hello,
i've seen some posts with enhancements of the "old" proxmark3 eG Bluetooth options and lcd .
I'm not sure if theese posts where ideas or now implemented.
so: is there a newer hardware on the marked?
if yes, i am highly interested to buy a ready assembled one. this is the only way for me to support the community.
or wait, i can deliver some plots from unknown rfid tokens and cards. i have some devices which i am not able to recognize with the given types of the proxmark, but this is another story.
Offline
Bluetooth support etc is in a very early design state, so no - theres no new hardware on the market yet. I appreciate your will to help the community, i am sure some of the more analytic-centered users welcome it (Im mainly into development of firmware/client).
Offline