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.
Yep, it's all good, flashed the bootloader a couple of times and it succeeded. Btw "hw ver" shows "#db# bootrom: Missing/Invalid version information"
$ client/flasher.exe -b bootrom/obj/bootrom.elf Loading ELF file 'bootrom/obj/bootrom.elf'... Loading usable ELF segments: 0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94 1: V 0x00200000 P 0x00100200 (0x0000172c->0x0000172c) [R X] @0x294 Waiting for Proxmark to appear on USB... Found. Entering bootloader... (Press and release the button only to abort) Waiting for Proxmark to reappear on USB.... Found. Flashing... Writing segments for file: bootrom/obj/bootrom.elf 0x00100000..0x001001ff [0x200 / 2 blocks].. OK 0x00100200..0x0010192b [0x172c / 24 blocks]........................ OK Resetting hardware... All done. Have a nice day! $ client/proxmark3 proxmark3> hw ver #db# Prox/RFID mark3 RFID instrument #db# bootrom: Missing/Invalid version information #db# os: svn 389-suspect 2010-02-26 20:22:29 #db# FPGA image built on 2009/12/ 8 at 8: 3:54 proxmark3>
Heh, as luck would have it something went wrong, I don't think it's a problem with the source code, just something weird with the USB bus, I'll recover with the JTAG and try again
Flashing... Writing segments for file: bootrom/obj/bootrom.elf 0x00100000..0x001001ff [0x200 / 2 blocks].. OK 0x00100200..0x0010192b [0x172c / 24 blocks]...........write failed: usb_reap: timeout error! Trying to reopen device... proxmark3> ReceiveCommandPoll returned 0 Error: Unexpected reply 0x0000 (expected ACK) ERROR Error writing block 11 of 24
Thanks iZsh and and marcan, the latest changes are pretty awesome.
I compiled the latest r405 tree in the proxspace environment (devkitARM-r27) and it compiles fine, no warnings or errors. The main os flashes and appears to work (issued some lf and hf commands and data plot window, but no antenna and no actual tag reading)
The bootrom fails to flash, see out output below (i've deleted some progress dots ... for brevity):
$ client/flasher.exe -b bootrom/obj/bootrom.elf Loading ELF file 'bootrom/obj/bootrom.elf'... Loading usable ELF segments: 0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94 1: V 0x00200000 P 0x00100200 (0x0000172c->0x00001780) [RWX] @0x294 Error: PHDR file size does not equal memory size (DATA+BSS PHDRs do not make sense on ROM platforms!) Error while loading bootrom/obj/bootrom.elf $ client/flasher.exe armsrc/obj/fullimage.elf Loading ELF file 'armsrc/obj/fullimage.elf'... Loading usable ELF segments: 0: V 0x00102000 P 0x00102000 (0x0000a4bc->0x0000a4bc) [R ] @0xb4 1: V 0x00110000 P 0x00110000 (0x000140b8->0x000140b8) [R X] @0xa570 2: V 0x00200000 P 0x001240b8 (0x00000004->0x00000004) [RW ] @0x1e628 Note: Extending previous segment from 0x140b8 to 0x140bc bytes Waiting for Proxmark to appear on USB... Found. Entering bootloader... (Press and release the button only to abort) Waiting for Proxmark to reappear on USB... Found. Flashing... Writing segments for file: armsrc/obj/fullimage.elf 0x00102000..0x0010c4bb [0xa4bc / 165 blocks].....<deleted>.. OK 0x00110000..0x001240bb [0x140bc / 321 blocks]....<deleted>.. OK Resetting hardware... All done. Have a nice day!
I don't know about crapto and mfoc but the latest proxspace compiles the rest of the source tree fine. Download from http://code.google.com/p/proxmark3/downloads/list and extract.
Check the runme.bat in the root directory and adjust MYPATH to match the path where you extracted the archive, then run it and type make to compile the svn.
Rather than have you read through other threads, it'd be easier to explain again.
Have a look at the output of the first post in this thread, the WriteBlock(124000 completes flashing the block 124000-1240100 and the flasher should probably just quit there, however some compilers create an elf file with extra segments. The parser code sees that extra segment and does WriteBlock(1240b8 which effectively overwrites the just flashed range 124000-1240b7.
I admit I don't understand the interaction between compilers and the segments they generate in .elf files so I don't know the significance of that last small segment containing just 4 bytes "01 00 00 00" but in practice if I binary patch the elf file to cancel out that last segment, the image flashes OK and I have a functional board, so I don't know if the proper thing to do is to ignore those last 4 bytes or try and flash them intelligently by merging them into the last written segment when there is an overlap.
Strike a ballance where the 125 and 134 Khz voltages are about equal and you're done, looking at your output you're already there.
I don't know why the LF optimal is not reporting the correct value, can you open the plot window, do a tune and losamples and post the picture of the waveform? It should look line a bell curve with the peak at about 129Khz which is 94 on the x asis, IIRC.
Looking at the wxwidgets screenshots page and the plethora of applications using it, I imagine wxwidgets is powerful enough. Whether we want to switch from Qt to wxwidgets is probably worth some consideration or debate.
While tidying up cockpit, I also propose to delete doc/readme.txt as it's no longer applicable, also should doc/changes.txt go as well? I don't see a reason to keep it.
Hi iZsh, I'm simply trying to keep my own development environment up to date with the latest changes, I just today, with a bit of help from someone managed to compile in Qt libraries, so I can bring up the plot window on the client.
I believe that if I endure a lot of grief setting up a functional development environment and sorting out through the dozens of little things that usually go wrong when assembling a bunch of disparate systems into one intergrated environment, it is worthwhile packaging that up and sharing it with others, so they don't have to pull their hair out duplicating my efforts. Do you not agree that providing a ready made ProxSpace like environment is beneficial to others ?
I could for example now easily integrate Qt into ProxSpace and update it.
I also propose to delete the cockpit directory as that is no longer useful (and is windows specific), its functionality is replicated by the top level Makefile. As such instead of the windows users dropping into a windows command prompt, they will be instead dropped into the MSYS shell. This further brings together the different OS environments into a more unified one.
How did the tests I suggested go?
Oh wait, you'll love this next one, the client doesn't build with the GUI "graph window" anymore, looking into what's required but it seems I need to download Qt for MinGw which is another 260Mb download, so the ProxSpace will most likely blow up after install to at least half gig of disk space
OK and I just verified a flash, flashing the elf produced by the compiler will kill the board but that is not an issue with the compiler, it is a problem with the elf parser code in the current SVN (Adam, this is why you end up with a constantly rebooting board).
Since I know what I'm doing, I binary patched the elf file with a hex editor to kill the extra segments that are causing the problem and the flash was successful:
C:\ProxSpace\pm3\client>flasher.exe os ..\armsrc\obj\osimage.elf Waiting for Proxmark to appear on USB... Found. Flashing os from ..\armsrc\obj\osimage.elf count=5 phoff=34 type=1 offset=0 paddr=0 vaddr=0 filesize=d4 memsize=d4 flags=6 align=8000 type=1 offset=8000 paddr=110000 vaddr=110000 filesize=140b8 memsize=140b8 flags=5 align=8000 flashing offset=8000 paddr=110000 size=140b8 WriteBlock(110000, 256, f8 b5 57 46 46 46 c0 b4 ... f0 b5 5f 46 56 46 4d 46) WriteBlock(110100, 256, 44 46 f0 b4 95 b0 0d 90 ... 04 9e 40 42 76 42 03 96) ...blah blah... WriteBlock(123f00, 256, 67 2c 20 67 6f 74 20 6c ... 29 e1 ff ea 78 47 c0 46) WriteBlock(124000, 184, 99 fa ff ea 78 47 c0 46 ... ff ff ff ff ff ff ff ff) type=1 offset=20000 paddr=0 vaddr=200000 filesize=4 memsize=4 flags=6 align=8000 type=1 offset=20008 paddr=0 vaddr=200008 filesize=0 memsize=8066 flags=6 align=8000 type=1 offset=27fe0 paddr=0 vaddr=20ffe0 filesize=0 memsize=10 flags=6 align=8000 done. Have a nice day! C:\ProxSpace\pm3\client>proxmark3 proxmark3> hw v #db# Prox/RFID mark3 RFID instrument #db# bootrom: svn 310-suspect 2010-01-10 03:38:55 #db# os: svn 368-suspect 2010-02-22 07:20:16 #db# FPGA image built on 2009/12/ 8 at 8: 3:54 proxmark3> exit C:\ProxSpace\pm3\client>
To also answer your other question about "Waiting for Proxmark to appear on USB...", that is because the current development is driven mainly by the linux crowd and they have chosen in the name of uniformity and cross-platform compatibility to use libusb, and I'm not begrudging that since I know where they're coming from, but the hardware is no longer plug'n'play on the windows side, you have to install some drivers, so the proxmark appears in your device manager under "LibUSB-Win32 Devices" instead of under "Human Interface Devices".
Since this is a "hot off the press development", there are no instructions to make those drivers unless you know what you're doing.
This is the magic: run msys\mingw\bin\inf-wizard.exe, it is a GUI app, click next, select the device with PID/VID 9AC4/4B8F, on the next screen leave everything as is (or you can put proxmark3 in the manufacturer name), click next and save the files back in msys\mingw\bin
Next go into the Windows Device Manager (right click My Computer, select Manage) and expand the Human Interface Devices tree, double click each device in turn and select the Details tab until you find the one with PID/VID 9AC4/4B8F, exit that dialog and right click that last device, select Update Driver, select "No" to windows connecting to Windows Update, select advanced on the next screen, select "Don't search, I will choose...", select "Have Disk", then browse to msys\mingw\bin and let it install the driver.
Your PM3 should now appear under "LibUSB-Win32 Devices", phew... then you can flash it with the flasher (don't as it will kill it).
Final word, please both you and others understand that you are playing with NON STABLE code, brand new developments in procedures for using the board, etc so please don't whinge if things arent' smooth, stick to the "ProxSpace2009 Summer edition" for now and let us finish this to the point where we can make a proper release. BTW the new ProxSpace I just uploaded, the one marked UNSTABLE, is not a release, it should NOT be use by anyone except those that are doing active development on the Windows platform, I can't stress that enough. If this is causing too much confusion I'll be happy to delete that file (insert smilies in that last paragraph, I'm not angry, simply trying my hardest explain where we are so that everyone is crystal clear).
Can you try something for me, run 0setpath.bat then cd ..\armsrc and run the command
perl ../tools/mkversion.pl .. > version.c || cp ../common/default_version.c version.c
Try it several times in a row, then cd ..\bootrom and try that command again, several times, does either of those tests cause the crash?
To answer your question, I tried this compile environment ina virtual machine on a pristine fresh install of WinXP Pro SP3 latest sevice packs, nothing else installed except AVG 8.5 antivirus. My compile output is exactly identical to the one you posted above except without the perl crash in the second call.
I have *only* tried the compile functionality and that it produces the expected output files, I have no flashed them yet on a board as my board was at home. Will try now and let you know.
The environment was verified to compile without errors but that doesn't mean that the current SVN is without issues, hence the unstable label.
And that perl error is weird, the first call to perl in armsrc completes fine but the second call in bootrom seems to fail even though both call do exactly the same thing but in different directories, does that happen every time ?
Sorry just realised that the ProxSpace was missing this lib. If you donloaded it, no need to re-download the new one, just put this lib in msys\mingw\bin
Would it be a good idea to compile the client binaries static so as not to have this issue of missing libs when moving them to a non development system ?
Instead of creating detailed instructions on setting up the development environment, I opted to create a new ProxSpace archive with the entire environment already set up, with both ARM and x86 compilers, see packages.txt in the root of the archive for the packages used. It's available for download from here, use 7zip to extract it the root of C:\ then run 0setpath and 5makeall in the cockpit directory. The archive extracts to 10x the size so about 260Mb free space is needed.
If you choose to extract it to another drive/path = <new_path>, you must modify the paths in the files <new_path>\ProxSpace\pm3\cockpit\0setpath.bat and <new_path>\ProxSpace\msys\etc\fstab
I can't seem to use relative paths in 0setpath anymore due to "make -C .. -s _test" in _checkmake.bat throwing a uname not found error, if someone has any ideas, let me know.
Nevermind, I sorted it. I tried Activestate Perl 5.10 which behaved OK in that respect but had some other issues, in the end I used a cygwin disto Perl 5.8.6 which seems to work OK. It's a minimal install, just the perl.exe and some dlls which is enough for what we use it currently.
I don't know perl either, that string looks almost like a regexp, in any case I tested this on a pristine XP VM reinstalling every package from scratch and the behaviour is the same.
I think rather than waste a lot of time getting to the bottom of this, it would be easier to modify mkversion.pl to get around this issue so if there are no objections I will use the code "($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time);" to extract the date/time and create $ctime, the net result should be the same on all platforms. Any objections?
The issue seems to be with sprintf, example code here:
#!/usr/bin/perl $local_time = gmtime(); print "Local time = $local_time\n"; ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time); $year = $year + 1900; print "Formated time = $mday/$mon/$year $hour:$min:$sec\n"; my @compiletime = gmtime(); my $ctime = sprintf("%6\$04i-%5\$02i-%4\$02i %3\$02i:%2\$02i:%1\$02i", @compiletime); print "compiletime @compiletime\n"; print "ctime $ctime\n";
$ perl test.pl Local time = Sun Feb 21 08:31:44 2010 Formated time = 21/1/2010 8:31:44 compiletime 44 31 8 21 1 110 0 51 0 ctime %6$04i-%5$02i-%4$02i %3$02i:%2$02i:%1$02i
wbahn, there will be precompiled releases of stable code such as the Summer 2009 release, however if you absolutely must have the latest features, I'm affraid the only way is to compile the latest code yourself.
iZsh, I noticed after deleting and reinstalling MinGW, etc that my perl was gone (needed for the ARM side) so I installed perl-5.6.1_2-1-msys-1.0.11-bin (which required libcrypt as well), anyway the compile now fails because the version.c produced by mkversion.pl has an invalid string, basically $ctime now produces a line like this "%6$04i-%5$02i-%4$02i %3$02i:%2$02i:%1$02i".
Any ideas why this version of perl would do that?