Recovering from bricked?
- MikeB
- 9x Developer
- Posts: 18010
- Joined: Tue Dec 27, 2011 1:24 pm
- Country: -
- Location: Poole, Dorset, UK
Re: Recovering from bricked?
erskyTx/er9x developer
The difficult we do immediately,
The impossible takes a little longer!
The difficult we do immediately,
The impossible takes a little longer!
Re: Recovering from bricked?
That's what I meant to say. The configuration screen in ePee.
Sent from my DROID BIONIC using Tapatalk 2
Sent from my DROID BIONIC using Tapatalk 2
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: Recovering from bricked?
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.
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
- Posts: 4327
- Joined: Thu Dec 29, 2011 3:44 am
- Country: -
- Location: Los Angeles, CA USA
Re: Recovering from bricked?
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
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
Re: Recovering from bricked?
What about the capacitor on the reset line?
Have you tried to remove it?
Reinhard
Have you tried to remove it?
Reinhard
Re: Recovering from bricked?
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
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
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.
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
- Posts: 4327
- Joined: Thu Dec 29, 2011 3:44 am
- Country: -
- Location: Los Angeles, CA USA
Re: Recovering from bricked?
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?
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?
Re: Recovering from bricked?
Did you remove the capacitor on the reset line?
My er9x/Ersky9x/eepskye Video Tutorials
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
https://www.youtube.com/playlist?list=PL5uJhoD7sAKidZmkhMpYpp_qcuIqJXhb9
Donate to Er9x/Ersky9x:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=YHX43JR3J7XGW
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: Recovering from bricked?
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.
I can give you a copy. Upgrading the programmer is indeed easy.
- ShowMaster
- Posts: 4327
- Joined: Thu Dec 29, 2011 3:44 am
- Country: -
- Location: Los Angeles, CA USA
Re: Recovering from bricked?
I reinstalled it early on so the answer is "no" and I'll try that next!jhsa wrote:Did you remove the capacitor on the reset line?
Good question, thanks.
ShowMaster
Sent from my iPod touch using Tapatalk
- ShowMaster
- Posts: 4327
- Joined: Thu Dec 29, 2011 3:44 am
- Country: -
- Location: Los Angeles, CA USA
Re: Recovering from bricked?
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.Romolo wrote: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.
Thanks
ShowMaster
Sent from my iPod touch using Tapatalk
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: Recovering from bricked?
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.
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.
- Attachments
-
- firmware.hex.zip
- (4.26 KiB) Downloaded 837 times
-
- 9x Developer
- Posts: 1109
- Joined: Sat Dec 31, 2011 12:11 am
- Country: -
- Location: Massa (MS), Tuscany, Italy
Re: Recovering from bricked?
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.
and the 2009 version has a bug for atmega 2560
that's why i compiled my own version, porting some mod from gruvin9x project.
Re: Recovering from bricked?
I see. With the betemcu.cn units i used the 2009 stock firmware with my 9x.