Home › Forums › TinyG › TinyG Support › TinyG won't boot: SpDir light flashing constantly
- This topic has 34 replies, 11 voices, and was last updated 7 years, 8 months ago by cmcgrath5035.
-
AuthorPosts
-
September 30, 2014 at 11:21 pm #6796themijMember
Hello,
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 mismatchWhat 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.
Thanks in advance for your help!
Alex
October 1, 2014 at 6:40 am #6797cmcgrath5035ModeratorWhile 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:For comparison, here is a somewhat dated download and flash session, run from a Linux machine
October 1, 2014 at 10:14 am #6802themijMemberFirst off, thanks for your reply.
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.
I’m running a Mac and I’ve reproduced the session output below. I checked the file and it appears that everything is good, at least according to the last section of this page: https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware
$ avrdude -p x192a3 -c avr109 -b 115200 -P /dev/tty.usbserial-DA00XHPY -e -U flash:w:~/Downloads/tinyg-edge-438.02.hex 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: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s avrdude: Device signature = 0x1e9744 avrdude: erasing chip avrdude: reading input file "/Users/mijalis/Downloads/tinyg-edge-438.02.hex" avrdude: input file /Users/mijalis/Downloads/tinyg-edge-438.02.hex auto detected as Intel Hex avrdude: writing flash (117552 bytes): Writing | ################################################## | 100% 14.71s avrdude: 117552 bytes of flash written avrdude: verifying flash memory against /Users/mijalis/Downloads/tinyg-edge-438.02.hex: avrdude: load data flash data from input file /Users/mijalis/Downloads/tinyg-edge-438.02.hex: avrdude: input file /Users/mijalis/Downloads/tinyg-edge-438.02.hex auto detected as Intel Hex avrdude: input file /Users/mijalis/Downloads/tinyg-edge-438.02.hex contains 117552 bytes avrdude: reading on-chip flash data: Reading | ################################################## | 100% 17.68s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0000 0xff != 0x0c avrdude: verification error; content mismatch avrdude done. Thank you.
Thanks again for your help,
Alex- This reply was modified 10 years, 1 month ago by themij.
October 1, 2014 at 10:26 am #6804themijMemberI also did a verbose output for avrdude and got the following information:
Using Port : /dev/tty.usbserial-DA00XHPY Using Programmer : avr109 Overriding Baud Rate : 115200 AVR Part : ATxmega192A3 Chip Erase delay : 0 us PAGEL : P00 BS2 : P00 RESET disposition : dedicated RETRY pulse : SCK serial program mode : yes parallel program mode : yes Timeout : 0 StabDelay : 0 CmdexeDelay : 0 SyncLoops : 0 ByteDelay : 0 PollIndex : 0 PollValue : 0x00 Memory Detail : Block Poll Page Polled Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 prodsig 0 0 0 0 no 50 50 0 0 0 0x00 0x00 fuse1 0 0 0 0 no 1 0 0 0 0 0x00 0x00 fuse2 0 0 0 0 no 1 0 0 0 0 0x00 0x00 fuse4 0 0 0 0 no 1 0 0 0 0 0x00 0x00 fuse5 0 0 0 0 no 1 0 0 0 0 0x00 0x00 lock 0 0 0 0 no 1 0 0 0 0 0x00 0x00 data 0 0 0 0 no 0 0 0 0 0 0x00 0x00 eeprom 0 0 0 0 no 2048 32 0 0 0 0x00 0x00 application 0 0 0 0 no 196608 512 0 0 0 0x00 0x00 apptable 0 0 0 0 no 8192 512 0 0 0 0x00 0x00 boot 0 0 0 0 no 8192 512 0 0 0 0x00 0x00 flash 0 0 0 0 no 204800 512 0 0 0 0x00 0x00 usersig 0 0 0 0 no 512 512 0 0 0 0x00 0x00 fuse0 0 0 0 0 no 1 0 0 0 0 0x00 0x00 Programmer Type : butterfly Description : Atmel AppNote AVR109 Boot Loader
October 1, 2014 at 12:27 pm #6806aldenMemberCan 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:
October 1, 2014 at 12:29 pm #6807themijMemberYes, I’m pulling from that link. Here are the beginning and ends of my text file, as viewed in vi (click the photo to see both in imgur):
http://imgur.com/TE8npMl,91cy3kw
Thanks,
Alex
- This reply was modified 10 years, 1 month ago by themij.
October 2, 2014 at 10:41 pm #6827cmcgrath5035ModeratorAlex
The number of bytes written , 117,552, seems reasonableDo you have vi adding the line numbers?
They should not be part of the file.Here are the last four lines of the file as I see it (Linux, kate editor)
:10CB04002E31660025302E32660025302E33660025 :10CB140025302E34660025302E35660025302E361D :0CCB2400660025302E37660025660000F4 :00000001FF
Same hex, no line numbers
January 22, 2015 at 3:30 pm #7300MrWMemberHas 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.
January 22, 2015 at 6:29 pm #7301cmcgrath5035ModeratorWe never heard back from member themij so I assumed something fixed it.
I recently used avrdude ver 6.1 to upgrade to 438.02 from my Linux system.
Some perhaps useful lines in the update log:
avrdude -p x192a3 -c avr109 -b 115200 -P /dev/ttyUSB0 -e -U flash:w:tinyg-edge-438.02.hex 2>flash_err.log ......... avrdude: verifying ... avrdude: 117552 bytes of flash verified avrdude done. Thank you.
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 reply was modified 9 years, 9 months ago by cmcgrath5035.
- This reply was modified 9 years, 9 months ago by cmcgrath5035.
January 23, 2015 at 4:25 am #7304MrWMemberNo joy with the -e option (same result as before). I guess I will have to contact Synthetos. Thank you for your rapid reply!
January 23, 2015 at 8:05 am #7305cmcgrath5035ModeratorWhat version of avrdude do you have?
avrdude -v
One more thing you could try is here:A relatively new development – appears only ready for OSx and Windows, although you could probably run under Linux will a little effort.
August 8, 2015 at 2:37 pm #8184bvi8370MemberThis 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.
I’m really starting to regret buying the Tinyg…
Anyone has suggestions?
August 8, 2015 at 5:02 pm #8185cmcgrath5035ModeratorIf 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.August 8, 2015 at 5:38 pm #8186bvi8370MemberHere’s the cmd I’m using:
avrdude -p x192a3 -c avr109 -b 115200 -P COM3 -U flash:w:tinyg-master-440.18.hex
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.
Thanks for your help!
- This reply was modified 9 years, 3 months ago by bvi8370. Reason: posted incorrect post processor used
August 8, 2015 at 8:55 pm #8188cmcgrath5035Moderatoravrdude -p x192a3 -c avr109 -b 115200 -P COM3 -U flash:w:tinyg-master-440.18.hex
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
-
AuthorPosts
- You must be logged in to reply to this topic.