its the latest spjs version? ...running on a raspberry pi.
iirc, garbled text was in the console as i pressed run. it could also have been in the gcode window... its all fuzzy now.
thought gcode actually loaded up fine in chillipeppr as the toolpaths looked right in the graphical viewer.
chillipeppr on win 7 x64 machine.
440.20 firmware on the tinyg.
hmmm was connecting through wifi on my laptop. could wifi be a cause?
i currently don't have an avr programmer... but if need be i could buy one i guess. if it'll fix the board for sure??? i'm based in south africa so logistics is a bit of an issue :-/
OK, you were running tinyG 440.20.
Now you have a constantly flashing spinDir LED?
That means bootloader is running
You then tried to reload 440.20?
And your did that using the SPJS 1.86 on RasbPi FW upgrade process?
And then your saw the verification error?
BTW, no obvious reason WiFi connection to SPJS would be the issue
nope never tried updating through Raspberry... plugged the tinyg into my winx64 machine via usb and used avrdude. i get exact same behaviour as KingBubbaTruck describes. also tried -e in command line with no success. gonna try updating using my mac... though i doubt it will make a difference...
and hey thanks for trying to help...
nope never tried updating through Raspberry… plugged the tinyg into my winx64 machine via usb and used avrdude. i get exact same behaviour as KingBubbaTruck describes. also tried -e in command line with no success. gonna try updating using my mac… though i doubt it will make a difference…
and hey thanks for trying to help…
Please be a bit more specific (I am gathering data here)
On Win64, you attempted to flash from a CMD window, using avrdude from arduino dev environment? Or describe
On OSx, you used the tinyGUpdater app from Synthetos web? or ?
This looks like a fuse issue, for which a solution may soon be available (being worked by devs), this info may help.
Have you done FW updates successfully in the past?
It is not at all clear (to me) how fuse state could be changed.
no worries. i'll provide more info as required. thanks again for the feedback.
>> On Win64, you attempted to flash from a CMD window, using avrdude from arduino dev environment?
affirmative. i even tried using latest avrdude version. same results unfortunately.
>> On OSx, you used the tinyGUpdater app from Synthetos web?
yup. used the app. result as above (in my previous post).
yes i did initially update the firmware when i first got the tinyg a few months back (using avrdude/winx64). then again i think when 440.20 came out? ..or was that spjs release... i make a point of keeping everything updated to the latest 'stable' release. in any case all was going swimmingly as i was building my machine.... until yesterday. never thought chillipeppr can be so vicious like that! also i only had stepper motors and the RasPi connected to the tinyg. no limit switches/superpid or anything like that yet.
only thing i haven't tried is using a atmel programmer as i don't have one... do have a mini adafruit programmer jobbie but i don't think that'll work with the chip on the tinyg...
only thing i haven’t tried is using a atmel programmer as i don’t have one… do have a mini adafruit programmer jobbie but i don’t think that’ll work with the chip on the tinyg…
I asked the tinyGupdater dev to look at this thread.
I believe he is working on a fix for this situation, has a Win64 beta that might help.
Is there someway to view the status of the lock bits and fuses without and avrisp MKII? I've got one on order, but just wondering if there's more info we could collect?
FWIW, I haven't done this before, but I do have a programmer on order. Unfortunately, it's being shipped from china, and won't be here for a little while.
I did read that just any programmer won't do, as you need one that supports the PDI interface used by the mega.
Here's where I got the info on the programmer required and how to do it.
I should have brents board in a few days. What I am hoping is that it's not actually bricked beyond repair with a AVRISP programmer. That is my goal. Then we can work together to get you a fix for your board. However, if the board's fuses are incorrect then I think it might be safe to assume you might have got a few of the "badly flashed" boards that went out. This is a new issue for us. Specifically the issue of HAVING a bootloader but not having the fuses set correctly. This is one of the guesses I have for the situation we find you and brent in. However it has never happened before. We have shipped WITHOUT bootloaders but never without the fuses set correctly AND having a bootloader.
I am hopeful that when I get the board it can be fixed without a programmer. However I cannot swear by this. Another option since you are in a different country is to reach out to a local hackerspace to see if they have an AVR available. I do not suggest this to shift the work onto you, but rather as a time saving option. Like you know it takes time to get a new board to South Africa. If I shipped it today you may not have it before the new year. However if this is the option that you would like to go please let me know and we can start that process.
Rest assured that we WILL get you up and running asap. We are very sorry for your issue with your TinyG board and are trying to fix you up!
hey ril3y,
thanks for the feedback and taking the time looking into this...
at this juncture i think its best to wait for the diagnosis on brent's board... and that its fixable.
in the mean time i've been trying to get hold of an avr locally... all else fails i'll have to take you up on that replacement :-/
Has this issue been solved yet? Im still waiting to hear back and was told to wait because i could do the fix myself instead of sending the board back for a replacement. Its been 6 days now since i have had any contact. I was told that there would be a write up before ril3y gets the boads to look at and i could test to see if it fixes the problem