-Ulfuse:w:0×75:m -Uhfuse:w:0xff:m
If you copied that line of text from a post here, please note that one 'x' is an actual 'x', but the other one is some weird superscript 'x' that avrdude cannot understand.
It’s recommended you crate a batch file (.bat) which you can run instead of typing in the command sting each time. It will execute all flashing / er ace commands as well as setting the fuse bits.
Thankyou! I got the line from the download link in the first post. Once I changed out the bad ‘x’, the output looks like it should - at least for my brand new chip. The chip on the driver I have stripped the 7135’s from, and mounted to my SRK driver is no longer responding. I get:
c:\avrusb>avrdude -p t13 -c usbasp -u -e
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=–1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Is that a sign this chip is probably gone bad? I’ve wiggled the clip and tried multiple times. But the new chip always works, and the old one never. If it is gone, at least I have one success.
Thanks again.
Yes I was using a batch file, but for some reason it would always give an error when I ran it. When I cut and pasted the separate commands from the batch file, all was good (so I was not actually typing it, i was cutting and pasting).
Thanks.
There are physical things that can happen to the driver that will prevent it from flashing. D1 diode shorted/bypassed/etc., one of the 'stars' grounded (they should all be clean/not bridged for the STAR momentary firmware), a bit of solder stuck somewhere it shouldn't be...
I doubt its bad, if its bad it’ll usually give a verification error or it will initialize several times and nothing else. Your not getting a connection at all. Are you hand soldering? Just a single extra drop of solder on one leg can keep the entire chip from making connection with the clip. I would say take some solder wick and suck all the extra off all the leg’s and try again. You could also solder flying leads (with female jumper ends) directly to pin 1,4,5,6,7 and 8 and try that.
Typing on phone so I missed comfy’s above post, like he said a shorted pin can cause a no connection (RC=–1) error. You can flash with an off-time cap in place (it’s not a short) but you can not flash with any stars grounded.
It was communicating with this chip initially, and I haven’t made any changes to the driver at all (it was mounted on the SRK driver before I started trying to program it). But I will double check it and make sure there is nothing physical happening like you say. Thanks.
OK. Thanks, if you don’t think it is bad, I will persevere with it. I didn’t actually mount the chip, I am using it on the nanjg 105c. I guess I could use a multimeter to ensure each pin is connecting correctly.
When struggling with Nanjg 105D (8*AMC7135) flashing and no problems at all with Nanjg AK-47A (3*AMC7135) I realized that AMC7135 load level on pin 6 of ATtiny13A is responsible. Just cut the track before flashing and it WILL work.
It complicates the process but you can make it simpler elsewhere. FT Convoy pill actually does not have to be soldered to Nanjg 105D (8*AMC7135) driver…
8)
Sounds odd too me. That’s PB1, the main PWM output for most ATtiny13A based firmwares here. You cut that trace and you’ll have no light at all. The 7135s are as far as I know all the same and wired the same way on the 105C and 105D, I don’t see why it would work on one but not the other. I’m guessing your problem is elsewhere…
Let me rephrase… cut the track and FLASHING WILL work, then you have to resolder the track, of course.
Hmmm - I’ve flashed plenty of 105D’s without problem.
Yes, it depends on flasher hardware and this thread is full of failure stories. USBasp or bit-bangging “ponyser” can not handle this sort of a load on MISO line reliably.
Interesting, are there any components on the back of this PCB? If not, then all data lines are directly connected between the IC and the programming connector. Now compare my USBasp called EvUSBasp http://www.ebay.com.au/itm/261545767062 It has a 4-resistor buffer block near the MISO line which does protect the IC but also degrades data output from it.
If you can confirm that there are no resistors at the back then I will remove the block and make direct connections instead.
When you refer to 105D you mean the 8 x AMC7135 version, right?
There’s resistors on the back, along with other components. Can u/load photo in the morning if you like.
Yes, 8*7135 105d.
I’ve already tried it with MISO resistor shorted but still no go. No problem when AMCs are cut off.
Great, but I still sounds weird that it would be because it’s a 105D. The AMC7135s have three pins. One goes to LED-, one goes to ground, and the last goes to PB1 on the MCU… exactly the same as the 105C… As far as I know, the only “officially” described difference with the 105D is the 7135 positions and removal of stars. I doubt that these changes are causing your flashing difficulties.
I never said it was because of 105D. It is about the number of AMCs - read it again. Flashing works on 3 of them but fails on 8. The more of them the higher the load, obviously. It is exactly like adding resistors in parallel.
You are right, my bad.
But instead of cutting and soldering all the time I think the easier solution is to get a different flasher. My first driver board for my M6 build (Mod: My SupFire M6 "BMF" edition (new beamshots in OP).) has 48 x AMC7135s on PB1. No issues at all flashing it.