Recovering from bricked?

[MikeB]

Never tried it, but you might have a look at http://sourceforge.net/projects/avrdude-gui/.

Mike.

[calla969]

That's what I meant to say. The configuration screen in ePee.

Sent from my DROID BIONIC using Tapatalk 2

[Romolo]

i reprogrammed by new atmega from c9x (but eepe is the same) by adding -B1000 as extra argument.
Then I wrote fuses from companion (the same can be done from eepe)
removed extra argument, detached the usbasp, reconnected and then I wrote the firmware.

[ShowMaster]

I could use some more ideas.
Using a know good USbasp programmer and eepe and C9x I've set the SCK in the AVRdude Burn Config to -B1000 and have the !MHZ 5 v ptp osc feeding pin 24 of the M64. I still get the "can't communicate error message" If I set the -B1000 to higher values the message also says SCK is 0 HZ?
I hope I'm missing a step here.
SM

[ReSt]

What about the capacitor on the reset line?
Have you tried to remove it?

Reinhard

[rperkins]

Just want to be sure you are not seeing this message ?
IIR you will see it with a usbasp with locked chinese, firmware , that supports autospeed

Code: Select all

avrdude: warning: cannot set sck period. please check for usbasp firmware update.

If you are I want to hookup my units to confirm that it doesnt say that with the open source firmware. It's been a couple months since I did my testing

On a only slightly related note. I had troubles using usbasp with the cheap chinese betemcu.cn units. It turned out to be a capacitor on the reset line. I spent a lot of time testing the chinese firmware that came on these units against the stock open source firmware. In the end the autospeed chinese firmware, while not open source, worked acceptably. Removing the cap on the reset line fixed my issue so I dropped my testing after that.

Here is a rough bash script I wrote that loops through the various speeds , and times the results for a given usbasp operations. the arrays in lines 2,3 correlate to the relationship between the -B timings and the sck period. I believe this relationship is hard coded in the usbasp src. My notes are at work but i will look it back up in the src code if you are indeed getting this message

It's been a couple months since I ran this code so it may not even run as is. the usbdevice is hardcoded and probably many other shortcomings in this code

Code: Select all

#!/bin/bash
declare timingList=(.5 1 2 5 10 31 62 125 250 500 1000 2000) # reference to avrdude -B timings
declare speedList=(1500 750 375 187.5 93.75 32 16 8 4 2 1 0.5) # reference to SCK speeds in khz
declare defaultList=(7 5 4 1) #reference to speedList elements for 8 32 93 750 khz
avrfile=avrfile.hex
avrInit=""
avrRead="-U flash:r:${avrfile}:i"
avrOperation=$avrinit
avrOperation=$avrRead
timefile=timefile
time="/usr/bin/time -a -o $timefile -f \"%E\""
avrdude="avrdude -B \${timingList[\$speed]} -p \$processor -P usb -c usbasp \$avrOperation"
redirect="2> /dev/null"

if [ $# -eq 1 ];then
	processor=$1
else
	echo "You need to pass the target processor value as the first option.  Try m8 m64 m328p."
	exit 1
fi


tail -f /dev/ttyACM0 &
tailfile=$!

if [ "$avrOperation" == "" ];then 
	task="initiate only"
else
	task="flash read"
fi
if [ -e $timefile ]; then rm $timefile; fi
clear
for speed in ${defaultList[@]};do
#for speed in 1 0 ;do
#for speed in 4 5;do
	echo  -n "Avrusb $task test at ${speedList[$speed]} khz SCK ...  "
	passed=0
	failed=0
	for each in {1..20} ;do
		trap "echo;echo Control-C trap caught;kill $tailfile; exit 1" 2 #traps Ctrl-C (signal 2)
		eval $time $avrdude  $redirect
		if [ $? -eq 0 ]; then
			echo -n p
			echo -n p > /dev/ttyACM0
			((passed++))
		else 
			echo -n f
			echo -n f > /dev/ttyACM0
			((failed++))
		fi
	#	sleep 2
	done
# lets trigger on the last attempt
echo -n t > /dev/ttyACM0
	echo -n " Passed $passed/$each  "
	if [ $failed -gt 0 ];then 
		echo -n " FAILED"
	else
		while read -r line; do # read the file that has the time values
			semi=$(expr index $line $:) # use semicolon to delimit time values
			minutes="10#${line:0:((--semi))}";seconds="10#${line:((++semi)):2}"; hundredths="10#${line:(($semi+3))}"
			declare -a allMinutes;declare -a allSeconds;declare -a allHundredths
			allMinutes=(${allMinutes[@]} "$minutes") # put values into arrays
			allSeconds=(${allSeconds[@]} "$seconds")
			allHundredths=(${allHundredths[@]} "$hundredths")
		done<$timefile
		each=0;totalMinutes=0;totalSeconds=0;totalHundredths=0;
		while [ $each -lt ${#allMinutes[@]} ];do # work through arrays, summing values
			totalMinutes="(($totalMinutes + ${allMinutes[$each]}))"
			totalSeconds="$(($totalSeconds + ${allSeconds[$each]}))"
			totalHundredths="$(($totalHundredths + ${allHundredths[$each]}))"
			((each++))
		done
		totalSeconds=$(($totalMinutes*60 + $totalSeconds + $totalHundredths/100))
		totalMinutes=0 # just rolled the minutes into the seconds
		totalHundredths=$(( $totalHundredths%100)) # the remainder of the hundredths
		totalTime="${totalSeconds}.${totalHundredths}"
		averageTime=$(echo "scale=2; $totalTime / ${#allMinutes[@]} " | bc)
		echo -n "averageTime $averageTime seconds "
			if [ -e $avrfile ]; then
				fileSize=$(stat -c%s $avrfile)
				echo -n "reading fileSize $fileSize  "
				throughput=$(echo "scale=2; $fileSize / $averageTime " | bc)
				echo -n "for throughput $throughput Bps"
				rm $avrfile
			fi
	fi
		unset allMinutes;unset allSeconds;unset allHundredths
		rm $timefile
	echo
done
kill $tailfile 

[ShowMaster]

I'm using the -B 1000 in C9X and then try a fuse reset. I get can't talk to target error message but what I do notice it it lists the clk speed as 1000Hz not KHz.
I find higher numbers for -B return a 0Gz?
Lower return a higher? A -B 4 returns something like 18500Hz?
So I'm not sure if reading the fuses or trying to program them with the error message containing a clk speed is a valid number?
In any case the -B 1000 and the 1Mhz Osc is not helping me connect to this M64 so do I call it dead and look for a replacement? I was hoping to help my friend out but maybe not unless a new M64 is purchased. His programmig cable is 10 In. long should I shorten it or does that matter?

[jhsa]

Did you remove the capacitor on the reset line?

[Romolo]

Do you have by chance two HK programmers ? i upgraded my one with open source firmware from 2009.
I can give you a copy. Upgrading the programmer is indeed easy.

[ShowMaster]

Did you remove the capacitor on the reset line?

I reinstalled it early on so the answer is "no" and I'll try that next!
Good question, thanks.


ShowMaster
Sent from my iPod touch using Tapatalk

[ShowMaster]

Do you have by chance two HK programmers ? i upgraded my one with open source firmware from 2009.
I can give you a copy. Upgrading the programmer is indeed easy.

yes I have spares so if you think I should try a new programmer firmware educate me and send it. Learn by doing is happening here.
Thanks



ShowMaster
Sent from my iPod touch using Tapatalk

[Romolo]

You need to connect the two programmers using flat, on the target one there are two pads near the atmega 8 processor you need to solder them together
the connect the programming usbasp to the pc and give the following command

avrdude -c usbasp -p atmega8 -P usb -U flash:w:firmware.hex

where firmware.he is the file contained in the zip.

[rperkins]

http://www.fischl.de/usbasp/

[Romolo]

the latest one is not working correctly with hk programmer
and the 2009 version has a bug for atmega 2560
that's why i compiled my own version, porting some mod from gruvin9x project.

[rperkins]

I see. With the betemcu.cn units i used the 2009 stock firmware with my 9x.