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.
Hello
I have built a Proxmark LCD using the same design as the NSL version, however I am having some problems connecting the device by USB.
I am unable to communicate with the device by USB in either windows or linux, it appears that the device is not being enumerated and cannot connect. I am using a bus pirate to flash the bootloader and full image by JTAG. Once flashed the device appears to work (The buzzer will sound on power up and if I edit the source to insert more buzzes at various points this also works). The LCD isnt working yet so I cannot confirm the device is fully working. Holding down the button to enter bootloader mode appears to do something but as soon as you release the button is appears to either reset or continue booting in the normal mode. I am not able to connect from USB in either mode.
I have tried various flashes, including several prebuilt elf files as well as compiling from different sources, including the latest Proxmark3 google code svn repo which is using USB-CDC.
I think it must be a problem with either flashing the AT91 or a problem with the USB on the device itself. I do not know where a problem with the device could lie as the USB connects pretty much directly to the chip so there isn't really anything I can think of that could be interfering with it.
Has anyone encountered a similar problem before or has any advice that could help me hunt the problem down? At present, not knowing if it is a hardware, software or flashing problem makes it quite difficult to tell.
Thanks for any advice in advance.
Offline
If it helps my dmesg looks similar to this:
[ 710.560359] usb 1-6.1: new high speed USB device using ehci_hcd and address 35
[ 725.632325] usb 1-6.1: device descriptor read/64, error -110
[ 740.809277] usb 1-6.1: device descriptor read/64, error -110
[ 740.984261] usb 1-6.1: new high speed USB device using ehci_hcd and address 36
[ 756.072217] usb 1-6.1: device descriptor read/64, error -110
[ 771.249348] usb 1-6.1: device descriptor read/64, error -110
[ 771.440348] usb 1-6.1: new high speed USB device using ehci_hcd and address 37
[ 781.848107] usb 1-6.1: device not accepting address 37, error -110
[ 781.921340] usb 1-6.1: new high speed USB device using ehci_hcd and address 38
[ 792.328098] usb 1-6.1: device not accepting address 38, error -110
[ 792.328361] hub 1-6:1.0: unable to enumerate USB device on port 1Offline
PM3 have Xilinx spartan II FPGA, while PM3-LCD have Xilinx spartan III. Their bitstreams are uncompatiable(fpga.bit). File fullimage.elf contains OS+bitstream.
What program have you used to flash your board? Does your board show some activity when you plug it into USB? Double check your soldering quality, maybe there is some short-circuit?
Offline
Hi, thank you for the assistance. I will check into the FPGA and make sure the fpga.bit is correct. Looking at the makefiles I though fpga.bit was compile when running make, is there anything special I would need to do to use the spartan III? Do you think that this could be preventing the USB from connecting?
I am using a bus pirate with OpenOCD and JTAG to flash the board. It seems that there is no communication with USB at all. When powered up the board will bleep (when using a firmware which includes bleeps) which suggests to me that the board itself is running as it should be. I have double and triple checked for shorts and cant find any.
Thanks for the help.
Offline
Since you are flashing fullimage.elf from pm3, it contains wrong bitstream plus new CDC interface rely on CDC-supported bootrom... So you should only flash bootrom+fullimage from PM3-LCD. There is ready fullflash on NSL, isn't it? Do you use bus pirate v4?
Small tip:Try holding down button while flashing bootrom.
Offline
I have tried multiple builds from various repos and the binary images from NSL with no luck. I am flashing with the bus pirate v3. I will give holding down the button while flashing the bootrom a go.
The number of different flashes I have tried causes me to think it may be a hardware problem, but checking the schematics shows that there is not much between the USB connector and the AT91 other than a couple of resistors which seem fine. NSL mention not to place D101 which joins USB_D+ and USB_D-. I originally connected this as it is shown in the NSL images but have since removed it with no difference.
As the board seems to boot and plays the various buzzes I have inserted in the code (including one when pressing the button) I would believe that the AT91 is working ok and the OS is loaded correctly however I cannot understand why the USB is failing. From reading up on the issue I am considering the 16mhz crystal may be a problem and am going to check the value of CKGR_MCFR to verify this is working (the board is at work so have to wait until tomorrow), however if this was faulty I would presume I would have more problems that just the USB connection.
Offline
I have narrowed it down to a timing problem. I have inserted four bleeps, delayed using SpinDelay(1000), instead of occurring one second apart it is closer to 2.5 seconds which explains the troubles I am having.
This obviously points to the 16Mhz crystal but is it a case of changing it and hoping for the best or could I change the frequency in code? If the crystal was damaged I would expect it just not to work, not to be slow...
Unfortunately I do not have anything to test it with, a multimeter shows 0.3v across the crystal when the proxmark is running but I do not know if this is what to expect. Any advice would be much appreciated.
Thanks.
Offline
I would strongly recommend to solder the crystal at low temperature(<150 degree C)using hot air. Otherwise you can damage it.
But if your crystal is damaged, the board will not start =>it will not bleep...
Offline
I used an iron to solder the crystal so damage is a possibility but as you say if that was the case it would not work at all. I have another crystal I could swap it with to rule it out. I cant imagine it but I wonder if I have just been incredibly unlucky and received a faulty crystal at the wrong frequency.
I believe that the load capacitor values can affect the frequency, do you know if this might be the case? Although I should think they would have to be quite wrong to affect the crystal that much.
Finally, do you think playing with the clock multipliers and dividers is an option? Unfortunately reading the MAINF register value by JTAG doesnt help as I believe the bus pirate is setting the frequency at this point. Can you think of any other way of testing the frequency in software?
Thank you for your help.
Offline
Going through the code I notice in bootrom.c the PLL Register is set as follows...
// PLL output clock frequency in range 80 - 160 MHz needs CKGR_PLL = 00
// PLL output clock frequency in range 150 - 180 MHz needs CKGR_PLL = 10
// PLL output is MAINCK * multiplier / divisor = 16Mhz * 12 / 2 = 96Mhz
AT91C_BASE_PMC->PMC_PLLR =
PMC_PLL_DIVISOR(2) |
PMC_PLL_COUNT_BEFORE_LOCK(0x50) |
PMC_PLL_FREQUENCY_RANGE(0) |
PMC_PLL_MULTIPLIER(12) |
PMC_PLL_USB_DIVISOR(1);and in proxmark.h there is...
#define PMC_PLL_COUNT_BEFORE_LOCK(x) ((x)<<8)
#define PMC_PLL_FREQUENCY_RANGE(x) ((x)<<14)http://www.atmel.com/Images/doc6175.pdf page 208 for the AT91SAMS512 shows that bits 3 to 13 of the register are for the PLLCOUNT and 14 and 15 are for the OUT (PLL Clock Frequency Range).
As PMC_PLL_COUNT_BEFORE_LOCK(0x50) =
((0x50)<<8) =
0101 0000
0000 0000
OUT is in fact being set to 01 and PLLCOUNT is being set to 0x10 (16)
I believe the correct value for OUT should be 00 (PMC_PLL_FREQUENCY_RANGE(0), however this has no effect due to PMC_PLL_COUNT_BEFORE_LOCK(0x50)). However, I am not sure what PLLCOUNT should be...
0x50 =
0101 0000
= 80
but the register is only 6 bits long giving a maximum PLLCOUNT of 63.
I am not sure if this could be causing my problems, any advice?
Offline
It seems that the crystal isnt the problem, I removed the original and replaced it.
Board behaves the exactly the same, interesting behaves in the same way with no crystal install. Proxmark seems to be using some other source for timing which must be causing the problems.
Offline
Weird situation... Do you have logic analyzer, oscilloscope? Can you take probes from AT91 pins?
Offline
Unfortunately not, I am going to have to continue to dig through the registers I think and make sure everything is as expected. Quickly running out of ideas though!
Offline
How it's going on?
Offline