Closed ekurt1 closed 7 years ago
Hi @ekurt1 first of all: The MFClassic_patch branch has been merged to the master branch and there also have been some bug fixes within the MF Classic emulation.
Regarding your problem: Since your Chameleon works fine, I cannot imagine that the problem is on the Chameleon firmware or hardware. Can you please do the following steps under Ubuntu:
dmesg | tail -n 20
in a terminal and print the output here in the issue.Which program are you using within ubuntu to connect with the Chameleon?
My primary way of connecting to the Chameleon had been on my Windows system, using TeraTerm and then the GUI-based application. I had never used Ubuntu to work with the device until I realized that it was not connecting on Windows, but I tried to use the socat method in the terminal to connect (but to no avail).
As for the terminal output (cut it down to just the USB activity):
ekurt@myLinux:~$ dmesg | tail -n 20 [ 3137.154548] usb 3-3: new full-speed USB device number 9 using xhci_hcd [ 3137.266593] usb 3-3: device descriptor read/64, error -71 [ 3137.482594] usb 3-3: device descriptor read/64, error -71 [ 3137.698584] usb 3-3: new full-speed USB device number 10 using xhci_hcd [ 3137.810597] usb 3-3: device descriptor read/64, error -71 [ 3138.027366] usb 3-3: device descriptor read/64, error -71 [ 3138.242493] usb 3-3: new full-speed USB device number 11 using xhci_hcd [ 3138.242621] usb 3-3: Device not responding to setup address. [ 3138.446748] usb 3-3: Device not responding to setup address.
@ekurt1 Do you have a programmer that supports the atxmega family? I recommend an erase and re-flashing the bootloader
I have a USBASP (via my Arduino), which can be modified to work with PDI to program the chip. However, can this be done with the chip still soldered to the Chameleon board, or will I have to unsolder the chip completely?
You have breakout for VCC, GND, DATA and CLOCK. There is no need to remove the chip.
As @Peterthegreat said, you just need to simply solder an 2x6 0.1" header (or bend it a bit to contact nicely even without soldering) on the edge where the PDI-pins are broken out anyway. There should be no need to cut traces or even remove the chip.
I am using a patched USBASP and a modified AVR ISP adapter. Remember to switch to 3.3V
Any news on this, @ekurt1?
Unfortunately no. I have been having trouble with trying to connect to the board to flash the bootloader. I patched my USBasp using two different methods, and despite the wiring modifications being correct, I have not been able to get avrdude to recognize the xmega. I took a break from it over the weekend, but I will take a look at it more this week.
I followed this tutorial for the USBASP and avrdude patch, and for the avrdude.conf you can take a look at issue #113
Note that on a x64 os, sometimes an load-page error may occur. Just rerun the flash command a few times.
@ekurt1 To be honest I cannot imagine a way how your bootloader has been altered as this usually is only possible by using a USBASP or by a bad firmware. However, the latter one can not be the case if you only used our firmware (since nobody else got this problem) and if you are sure you haven't used an ASP by accident ;) - then I think this could be a problem with your PC. Can you try flashing with another PC?
I forgot to mention in my original post, but I have tried to connect the board to several computers (Windows and Linux), and none could recognize the device, even with the correct drivers installed. The Chameleon does everything as expected when connecting or going into bootloader mode (based on the LEDs), but it will just not be recognized correctly. Could the issue be something wrong with the USB circuit? I have not tried a reflow of the board as I am not sure if that would cause more harm.
I am also still not able to get the USBasp to communicate with the board, and I had followed both of the links from Peterthegreat previously, so the USBasp works (used it to program another chip as proof) and it has the correct conf for the xmega. So could the issue be something wrong with the xmega communication in general? However, I am not sure how to go about resolving that.
Actually, I spoke too soon on the board's status. The antenna no longer works, or there is just no RFID signal coming from it. The LEDs light as they should, but I am not getting any signal from the antenna. It is possible the USBasp further messed something up, even though it could not recognize the chip.
@ekurt1 If the USBASP with avrdude did not recognized the chip (and you also had the wiring correct), there should be no change from the previous state. How can you tell the antenna no longer works? You tried a reader with the chameleon and it is not longer recognized?
Yes. I tried the chameleon with a reader since it had been working up until now, just not communicating over USB, but it is no longer recognized by the reader. I am not sure what the cause of this could be, but it is a separate issue from the USB issue.
Of note, I did have to resolder the battery case a few days ago since that fell off, and this would have been the first time I tried to use the chameleon after that, so something may have been damaged on the board.
What was the response from avrdude when you tried to connect ? Can you post pictures with the terminal?
I will post the terminal information once I return from work. Won't be for few more hours though.
Here is the output from avrdude:
What directly pops into my mind is that the sck period is too low. This results in a SPI frequency that is too high and thus the SPI programming data transfer does not work. The SPI frequency has to be smaller than 1/4th of the ATxmega's clock frequency. Try setting the sck period to 10µs for example. If I remember correctly you have to use -B 10
on the command line.
also, try adding -E noreset to the command line
Thanks for the ideas. Neither had worked, that was until I discovered that putting physical pressure on the board caused it to work. Only when I press down on the xmega chip itself did the RFID signal work and the computer recognize the board. In the end, it seems the issue was the physical connection of the components, so I think I will need to reflow the board.
For now, any advice on reflowing the board to reconnect the many solder points?
Take a look at this video. Clean and tin the soldering iron first. You will need to apply a lot of flux and use a good solder (60/40 or 63/37 Sn-Pb solder). Also use solder wick for the solder excess.
You can then use a multi meter to test continuity(diode test symbol). Test for shorts between neighbor pins , continuity form the USB jack to the chip and from the breakout pins to the chip.
I noticed that the board itself is high quality, so you should not worry about damaging the pcb routes if you applied pressure to the board.
Edit: since the board has solder mask, the operation should be easy. You should keep contact for at least 3 seconds after the solder reaches the melting point
Would it be better to use a solder reflow oven, since I don't not know which connections are bad? I use the oven to normally repair motherboards and GPUs, but I don't know how a small board like the Chameleon would respond with it.
I can also just go through each pin manually to resolder, but this just seems to be more error-prone with the many small components.
If you have soldering paste and you can dispense it properly to the terminals, you can go for the reflow oven (especially if you have done this before).
Whichever method you choose, always make a visual inspection of the soldering.
I forgot to post my update, but since USB seemed to be the only issue, I resoldered Pins 25-27 (PD5-7) individually on the xmega, since they correspond to the USB controls. Since then, I have had no issue in getting a consistent connection from the board via USB, and I was able to update the firmware to the latest version. For now, with the board working from the minimal repair, I will save a full reflow for when more extensive repairs are necessary.
Thanks again for everyone's help on the issue.
I only just discovered this issue recently when attempting to update the firmware, but my ChameleonMini RevG is not being recognized by my computer over USB (in Windows 10 and Ubuntu 16.04). Usually, it is assigned to COM4 in Windows, but I keep getting an error of an "unrecognized USB device." I reinstalled all drivers, and after several restarts, the card is still not recognized under the normal or bootloader modes.
Searching through previous issues, this may be related to the memory corruption issue. However, my ChameleonMini is working fine apart from the terminal connection to program it (I can toggle through my already programmed slots, and I can read/write to the slots from an NFC writer), so I am not sure what the issue could be. The board seems fine physically, so any help in pin-pointing the problem would be appreciated.
The last time I had the board connected to the computer was about 2 months ago, updating to the MFClassic_patch branch, since I was not having any luck in getting the card recognized by a specific reader.