We bought the TinyG a couple of weeks ago, and since then it has been running without issues. However, today, we tried to send a serial command to the controller, and the command didn't process. Upon resetting the TinyG (v8), the SpDir light flashes constantly.
This indicated to me that the TinyG was in programming mode. Using AVRDude to attempt to reprogram the TinyG gives this error at the end:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0x0c
avrdude: verification error; content mismatch
What is the best way to fix this issue? We don't have an AVRISP programmer on hand, and I feel this may be an issue with fuses or lock bits.
While nothing is impossible, the issue with fuses and lock bits was a start up production programming issue over a year ago and not likely on a recent production unit.
Do you recall what FW version was installed on your unit when you first started working with it?
You are correct, the flashing SpDir indicates the boot loader is in charge on the tinyG.
Can you describe a bit more about the avrdude session:
Running on Win, OSX, Linux?
What version are you attempting to flash to the tinyG?
Are you sure that the file you are (attempting to) flash is a hex, not ASCII?
You should probably be flashing version 438.02, which can be downloaded fron this site:
I don't remember (and can't query) which firmware version was on my TinyG before it crashed. However, we purchased it around 8 weeks ago directly from Synthetos.
I originally tried to flash v380.08 from the page you linked. Today I tried 438.02 and got the same error.
Can you look at the file in a text editor and verify that is an intel hex file? Sometimes people download an HTML file by mistake. Are you pulling from here:
Has this been solved? If so, I would appreciate a description of the solution. I have exactly the same problem. The board seemed to work fine for a while, but one day the SpDir LED never stopped flashing when I connected the power.
I tried to re-flash the firmware (I already had v 438.02 installed before the crash) using the method described above with exactrly the same result, namely that the verification failed.
I am eager to hear what happened after the last reply.
Did you use the -e option on your avrdude command line?
My upgrade failed without it, but did not write anything without it so a different failure signature than yours.
I WAS updating (from 425.something), so perhaps a "reflash" of 438.02 has a different signature.
This seems to confirm that build 438.02 loads 117552 bytes to flash.
If -e option does not work, you'll have to consult the Synthetos folks.
This issue just popped up for me as well. I upgraded to 440.16 a couple weeks ago and finally got my spoilboard installed last night. Everything was running fine - jogging, test cutting the Chilipeppr logo and grim reaper gcode I found somewhere.
Today's task was to level the spoilboard to the cutter in preparation to cut the t-track slots. I laid out the spoilboard in vcarve pro, created the tool paths and attempted to load them into Chilipeppr. Chilipeppr proceeded to buffer 10000 lines. As it was loading, there were numerous strange symbols for each line displayed in the feedback window. I checked the code in notepad++. It looked normal but I went ahead and resaved it to make sure it was just plain text. I tried the code in Chilipeppr again but the same thing happened - strange symbols. I looked at the Tinyg and saw the spdir LED flashing continuously. Resetting, power cycling and reseating the USB did nothing.
At this point I attempted to upgrade the firmware to 440.18 and edge 442.04. Both seemed to write but fail the verify process. Spdir continues to flash.
Json seems to connect to the Tinyg on COM3, but the buffer in Chilipeppr freezes and each configuration line has a yellow check.
Connecting to programmer: .
Found programmer: Id = "XBoot++"; type = S
Software Version = 1.7; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.
Programmer supports the following devices:
Device code: 0x7b
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude.exe: Device signature = 0x1e9744
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: current erase-rewrite cycle count is -269488145 (if being tracked)
avrdude.exe: erasing chip
avrdude.exe: reading input file "tinyg-master-440.18.hex"
avrdude.exe: input file tinyg-master-440.18.hex auto detected as Intel Hex
avrdude.exe: writing flash (118196 bytes):
Writing | ################################################## | 100% 11.10s
avrdude.exe: 118196 bytes of flash written
avrdude.exe: verifying flash memory against tinyg-master-440.18.hex:
avrdude.exe: load data flash data from input file tinyg-master-440.18.hex:
avrdude.exe: input file tinyg-master-440.18.hex auto detected as Intel Hex
avrdude.exe: input file tinyg-master-440.18.hex contains 118196 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 14.00s
avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdude.exe: verification error; content mismatch
avrdude.exe done. Thank you.
If Spin/Dir is still flashing, bootloader is still running.
SPJS may have connected to the ftdi hardware (on tinyG) but tinyG is not running if the bootloader is.
Make sure you exit CP and kill SPJS.
What upgrade procedure did you use?
You might want to try the procedure outlined here, if it is not what you used.
It looks the same as the one in the link you provided.
Both methods, avrdude and the updater return the same messages.
This one is worrisome:
avrdude.exe: verification error; content mismatch
This seems like a long shot, but I'm using a Tinyg post processor script that looks to be dated:
+================================================
+
+ G Code - Vectric machine output configuration file
+
+================================================
+
+ History
+
+ Who When What
+ ======== ========== ===========================
+ Saci 24/09/2012 Written
+================================================
POST_NAME = "TinyG (mm) (*.tap)"
FILE_EXTENSION = "tap"
UNITS = "MM"
+------------------------------------------------
+ Line terminating characters
+------------------------------------------------
LINE_ENDING = "[13][10]"
+------------------------------------------------
+ Block numbering
+------------------------------------------------
LINE_NUMBER_START = 0
LINE_NUMBER_INCREMENT = 10
LINE_NUMBER_MAXIMUM = 999999
+================================================
+
+ Formating for variables
+
+================================================
VAR LINE_NUMBER = [N|A|N|1.0]
VAR SPINDLE_SPEED = [S|A|S|1.0]
VAR FEED_RATE = [F|C|F|1.1]
VAR X_POSITION = [X|C|X|1.3]
VAR Y_POSITION = [Y|C|Y|1.3]
VAR Z_POSITION = [Z|C|Z|1.3]
VAR X_HOME_POSITION = [XH|A|X|1.3]
VAR Y_HOME_POSITION = [YH|A|Y|1.3]
VAR Z_HOME_POSITION = [ZH|A|Z|1.3]
+================================================
+
+ Block definitions for toolpath output
+
+================================================
+---------------------------------------------------
+ Commands output at the start of the file
+---------------------------------------------------
begin HEADER
""
"( Vectric Aspire post-processor for TinyG mm-no-arc )"
"( [TP_FILENAME] )"
"( File created: [DATE] - [TIME])"
""
"( Material Size: X= [XLENGTH], Y= [YLENGTH], Z= [ZLENGTH])"
""
"(Toolpaths used in this file:)"
"([TOOLPATHS_OUTPUT])"
""
"T[T] M6"
"G21G17G90"
"G0[ZH]"
"G0[XH][YH]"
"M3 [S]"
+---------------------------------------------------
+ Commands output at toolchange
+---------------------------------------------------
begin TOOLCHANGE
"M0"
"T[T] M6"
"M3 [S]"
+---------------------------------------------------
+ Commands output for rapid moves
+---------------------------------------------------
begin RAPID_MOVE
"G0[X][Y][Z]"
+---------------------------------------------------
+ Commands output for the first feed rate move
+---------------------------------------------------
begin FIRST_FEED_MOVE
"G1[X][Y][Z][F]"
+---------------------------------------------------
+ Commands output for feed rate moves
+---------------------------------------------------
begin FEED_MOVE
"[X][Y][Z]"
+---------------------------------------------------
+ Commands output for a new segment - toolpath
+ with same toolnumber but maybe different feedrates
+---------------------------------------------------
begin NEW_SEGMENT
""
"([TOOLPATH_NAME])"
""
"M03 [S]"
+---------------------------------------------------
+ Commands output at the end of the file
+---------------------------------------------------
begin FOOTER
"M5"
"M9"
"G0[ZH]"
"G0[XH][YH]"
"M2"
""
I there anyway this would cause the board to malfunction? Everything was fine before I attempted to load the g-code using this post processor.
Difference between your command and the one I reference is a "-e" option, which for reasons not well understood seems to be required in some (many, all?) upgrade instances.
Sorry, the post processor messages are very software package specific, can't comment