If the bootloader flashed OK, then hold down the button when you plug in the USB cable and it should appear on the USB bus, then while holding down the button you should be able to flash the osimage and fpgaimage. No need to JTAG.
And FFS make sure you use the client utilities from the client directory compiled from the Summer 09 (or whatever version you're flashing). Always always always always use the matching utilities for the version firmware that's flashed to your card.
The screen is worth $18 in singles however the factory only ship via DHL for $50 and only accept Western Union or Telegraphic Transfer (extra few dollars for that). The display is the KWH028Q06-F02 from Wandisplay.
I haven't even fitted the LCD to the prototype yet as I came across a weird bug in HF path of the analog section which I'm trying to get to the bottom of. Since the schematic hasn't changed since the last working prototype, it's either a PCB production issue, component failure or some weird layout issue.
Given that, and the cost of the LCD plus shipping, you'd be better off going for the v17 board if you want something quickly.
Generally removing coils from an inductor reduces its inductance making it resonate at higher frequencies. As your inductor already resonated at over 200Khz, removing coils shifts it in the wrong direction, you want to add instead.
I don't know if it's too late and if you could put those coils back on but since the software tells you the resonant frequency of the coil you could use that to calculate a new C capacitor value that would shift the resonant frequency down to 125Khz.
You know the current F (203Khz) and the C, solve for L
Once you know the L solve for C at 125Khz and find the new optimal C value....
I have a feeling you don't understand how antennas work, it is a tuned LC circuit where L stands for the coil and C is the capacitor already fitted to the board. Buying some random coil off the internet that does not specify the inductance of the coil but just says it's for "125Khz RFID" is no guarantee of success at all. Still at $3 it's no big loss either so worth a try
Let us know how it works out
Regarding your other post... I'll reply in that thread...
I have had similar issues in the past with the proxmark board, I don't think it's software related. The way I dealt with it was to remove power from the board for a few minutes then power up again. I thought it was something weird with my board but is seems you have the issue too... maybe if it happens again I will debug the hardware properly to see what the issue is.
Since you know about SVN, why not go to http://code.google.com/p/proxmark3/ and click on the Downloads tab? There are Summer 09 binaries, Winter 10 binaries as well as the latest updated ProxSpace environment that should compile just fine under Windows?
Also where is this expectation coming from, that the latest SVN contains stable code. You are accessing a development environment undergoing constant changes, the code may well not be stable!!!
And here is a test without recompiling or reflashing at all.
> reset init JTAG tap: sam7x.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600000f3 pc: 0x00119d92 requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x600000d3 pc: 0x00000000 > resume
To advance past bootrom code and into appmain
> halt target state: halted target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x600000f3 pc: 0x00119d10 > mdw 0xffffff60 0xffffff60: 00480000 > resume
Waitstate above was 0, just executed "hf 14a read"
> halt target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x800000d7 pc: 0x00000068
Processor now at address 0x68 = data abort, reset the board next
> reset init JTAG tap: sam7x.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3) srst pulls trst - can not reset into halted mode. Issuing halt after reset. target state: halted target halted in ARM state due to debug-request, current mode: Abort cpsr: 0x800000d7 pc: 0x00000094 requesting target halt and executing a soft reset target state: halted target halted in ARM state due to debug-request, current mode: Supervisor cpsr: 0x800000d3 pc: 0x00000000 > resume
To advance bast bootrom and into appmain again
> halt target state: halted target halted in Thumb state due to debug-request, current mode: Supervisor cpsr: 0x400000f3 pc: 0x001193a0 > mdw 0xffffff60 0xffffff60: 00480000 > mww 0xffffff60 0x00480100 > mdw 0xffffff60 0xffffff60: 00480100 > resume >
Just set the wait state to 1 above and verified it by reading the register back, then let the board run the code again and in the proxmark console try I reading the card again:
proxmark3> hf 14a read #db# 5214 cc cc #db# ready.. proxmark3> hf 14a list proxmark3> recorded activity: ETU :rssi: who bytes ---------+----+----+----------- + 0: : 52 + 156: 0: TAG 02 04 + 0: : 93 20 + 292: 0: TAG 80 40! 80 00! + 0: : 93 70 80 40 80 00 da 45 30 + 0: : 52 + 144: 0: TAG 02 00! + 0: : 93 20 + 292: 0: TAG 80 40! 80 00! + 0: : 93 70 80 40 80 00 da 45 30
This time the board runs and returns data with loads of crc errors.
All my tests and debugging is done with code compiled with -O0, I never actually managed to pinpoint the exact place where the variable is set to that incorrect value mainly because single stepping through the code never produces the error, it's only when the code is running full tilt that it errors.
On that note, I'll add the following observation. I tested the latest (disputed) bootrom code change submitted by marcan where he increases the Flash Wait State (FWS) from 0 to 1 and the crash doesn't occur when FWS=1 while it always occurs with FWS=0
Only the bootrom code was reflashed between tests, the main osimage code was not reflashed or recompiled. This excludes the compiler as a variable I think and it wouldn't be unthinkable that incorrect FWS has been a source of unexplained code instability in the past, however as marcan stated, due to the increased FWS, code runs slower and reading a HF tag now produces a lot of CRC errors and incorrect tag reads (all other things remaining equal, only changing FSW to either 0 or 1 and testing).
Breakpoint 1, 0x0011b740 in GetParity (pbtCmd=0x20fe90 "R", iLen=1) at iso14443a.c:70 70 dwPar |= ((OddByteParity[pbtCmd[i]]) << i); bt #0 0x0011b740 in GetParity (pbtCmd=0x20fe90 "R", iLen=2097508) at iso14443a.c:70 #1 0x0011bae8 in LogTraceInfo (data=0x20fe90 "R", len=2097508) at iso14443a.c:106 #2 0x0011e998 in ReaderTransmitShort (bt=0x0) at iso14443a.c:1564 #3 0x0011e998 in ReaderTransmitShort (bt=0x20fe90 "R") at iso14443a.c:1564 #4 0x0011ec20 in ReaderIso14443a (parameter=0) at iso14443a.c:1643 #5 0x00117e28 in UsbPacketReceived (packet=0x200044 "\205\003", len=64) at appmain.c:638 #6 0x00119c68 in HandleRxdData () at ../common/usb.c:435 #7 0x00119d8e in UsbPoll (blinkLeds=0) at ../common/usb.c:495 #8 0x0011833e in AppMain () at appmain.c:880 #9 0x00110052 in Vector () at start.c:32
I think I might have solved this one, seems after the board crashes and ends in Data Abort, the link register points to the address the crash was triggered, which following it back ends up being in GetParity(). Placing a breakpoint in there and running the board through that a few times there are certain times where the variable iLen=2097508 or some such large value. GetParity() is often used in conjunction with LogTrace() which also uses a memcpy(dest,src,iLen), you see where this is going, when memcpy is executed with the very large iLen it eventually runs out of RAM and tries to write out of bounds, hence the Data Abort (which incidentally corresponds to a memory access at address 0x400000).
Since I can't find any piece of code that actually sets iLen to such a large value, I followed a hunch and changed the declaration of iLen in LogTrace() from int to size_t which seems to have magically fixed the problem. If it's a typecasting issue, I believe there are many more of those hidden treasures in the code, unfortunately. I'll commit now.
Oh yeah, good call, so i compiled the code with -O0 and the behaviour is same but worse, the board now hangs and resets at that command (whereas before hitting the button would make it return). If I hit the debug button while it's hung it seems to be stuck at addr 0x68 which I believe is the data abort vector.
If I single step, the behaviour is even weirder... for example I breakpoint inside ReaderIso14443a then if I step "over" the functions, it seems to reliably hang at the first call to ReaderTransmitShort(wupa), but if I step "into", I seem to be able to single step all through that function and return back to the caller... does your board run fine with this winter release when executing that command regardless if there's a tag in the field or not?
I did some more testing today and I came across something weird, with latest SVN r412. When using the command "hf 14a read" the board seems to hang in read mode and doesn't return even after waiting a minute or so. Pressing the button aborts the read and the board is accessible again but hasn't managed to read the HF card in the field, example:
proxmark3> hf 14a read
Board appears to hang, wait 30 sec, press button, board spits out some bogus read status
#db# 33678 cc cc #db# ready.. proxmark3> hf 14a list proxmark3> recorded activity: ETU :rssi: who bytes ---------+----+----+----------- proxmark3>
Notice that there's nothing in the list despite the 33678 indicator. After a few hours of debugging, I managed to get the board to read a HF card by changing iso14443crc.c to remove the "static" keyword in the declaration of UpdateCrc14443 then add a header definition for UpdateCrc14443 to iso14443crc.h
I know this doesn't make sense, but I can reliably get the board to misbehave if I revert to original r412 code, recompile and reflash and I can fix it by making those changes. Can anyone else verify this?
Yes I'd tend to aggree, when I was last dong some development on the code late last year the code seemed flakey, like when it would crash then simply adding a printf statement would "fix" it. I had very little confidence in it, however in hindsight I believe a lot of that was due to the elf parser issues we recently fixed (thanx marcan) so the current (northern hemisphere) winter release should be a lot more stable.
I haven't had much time to actually test the functionality in terms of reading/writing tags but if anyone else has, please pipe up and let us know in this thread, so that if enough positive testing shows it is working, we can start recommending this firmware release as "the" one to use instead of the Summer 09.