Yet another spindle flashing light problem, why is it so easy to crash the TinyG

Home › Forums › TinyG › TinyG Support › Yet another spindle flashing light problem, why is it so easy to crash the TinyG

Tagged: 

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • April 29, 2016 at 5:00 pm #9629
    dgtlmoon
    Member

    Hi all
    I had the common problem where one minute I’m happily working away, next minute the tinyg stops responding and the spindle light is flashing

    Then I learn about uploading replacement hex/flash to the board but it still doesnt work.

    So then it turns out I need to use Ateml studio 6/7 and purchase yet another piece of hardware to reset the lock/fuse bits and get it running again

    here is my gripe.

    All I done was accidentally paste in the wrong code whilst using chilipepr and now I need to wait for weeks, spend more cash to get a controller and then learn more about programming the device to get it working again

    Seems there are dozens of people in the same situation I’m in, is there some possibility that the software could be modified so it doesnt completely confuse the board to the extent that it needs totally reprogramming by just simply uploading the wrong data to it through either a gcode sender or a gui like chilipepr?

    Seems like this is a big issue with TinyG

    April 29, 2016 at 10:30 pm #9630
    cmcgrath5035
    Moderator

    Sorry to hear of your problems.

    You may be integrating several different flavors of issues in concluding that your need a low level reflash (with the ICE tool).

    You should connect with Synthetos at this URL :

    Information about when you purchased may help identify if you tinyG was in the population that likely has a fuse issue. Returning the board to Synthetos for a reflash would be an option if you don’t want to try the ICE.

    Is the Spindle (SPIN) LED flashing or solid on, or is it the SpinDir LED?
    How long have you had your tinyG?

    What OS are you using to run SPJS?

    May 1, 2016 at 9:17 am #9635
    dgtlmoon
    Member

    Thanks for the reply! Ah so it’s not as simple as I thought then 🙂

    It’s the SPDir LED that flashes, I did try the avrdude reflash which worked but gave the error that led me to the page about using the additional piece of hardware to reset the LOCK bits with Atmel Studio 6

    I was running the TinyG behind the excellent serial-port-json-server on a Raspberry Pi

    I will send the other details to that contact form now

    thanks again!

    May 1, 2016 at 9:26 am #9636
    dgtlmoon
    Member

    Registered posting from czech republic to the US and back is insanely expensive.. 🙁 I have ordered the reprogrammer interface as that’s a cheaper way to atleast try first. it would be honestly cheaper to throw this unit in the bin and buy a new unit, even at $120USD 🙁

    May 1, 2016 at 4:52 pm #9637
    cmcgrath5035
    Moderator

    STOP!

    Before you buy anything, tell me more about your Pi – Pi1 or Pi2?
    WHat version of SPJS loaded?

    What is your PC OS? (Win, Linux, Mac)

    I tested SPJS 1.88 on Pi2 back in January, the Firmware flash feature did not work.
    It does not work with native Linux on PC either.
    Back then, only the Win_64 version of SPJS flashed properly.
    I don’t know if anything has changed with release 1.92 of SPJS.

    I can point you to a Linux desktop(laptop) based procedure that works, or you could temporarily bring up a windows SPJS to do your flashing.

    May 2, 2016 at 8:59 am #9641
    dgtlmoon
    Member

    Heya

    So it’s a rPi Model 2 B. Last I checked rPi’s dont run windows, so the answer is in my first comment there (Linux)

    I need to repeat myself here for the sake of keeping this ontopic – All I simply done was accidentally uploaded some binary data in the gcode field and now the device is requiring a reflash because the LOCK bits are not set right

    I see your reply here in the forum but I have not got a reply from your company about if my board is involved in the problems you mentioned

    I have tried reflashing the device with the information from other people who have also have had their board stuck in SPDir from https://www.synthetos.com/topics/tinyg-wont-boot-spdir-light-flashing-constantly/

    I have to admit that I really have zero windows experience but have been doing some atmel programming as a hobby for a few years from Linux using avrdude.

    So I followed https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware – I’ve tried the packaged Ubuntu avrdude as well as the one mentioned in the wiki

    root@dgtlmoon-XPS-15-9550:~/workspace/cnc/tinyg/arduino-flash-tools-master/tools_linux_64/avrdude/bin# avrdude -p x192a3 -c avr109 -b 115200 -P /dev/ttyUSB0 -e -U flash:w:../../../../tinyg-master-440.20.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.00s

avrdude: Device signature = 0x1e9744 (probably x192a3u)
avrdude: erasing chip
avrdude: reading input file "tinyg-master-440.20.hex"
avrdude: input file tinyg-master-440.20.hex auto detected as Intel Hex
avrdude: writing flash (118274 bytes):

Writing | ################################################## | 100% 10.91s

avrdude: 118274 bytes of flash written
avrdude: verifying flash memory against tinyg-master-440.20.hex:
avrdude: load data flash data from input file tinyg-master-440.20.hex:
avrdude: input file tinyg-master-440.20.hex auto detected as Intel Hex
avrdude: input file tinyg-master-440.20.hex contains 118274 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 11.14s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x0c
avrdude: verification error; content mismatch

avrdude done.  Thank you.

    The image looks correct

    
# md5sum tinyg-master-440.20.hex 
6d1ddc5e56784fc69ccec021735f7953  tinyg-master-440.20.hex

    
# head -n 5 tinyg-master-440.20.hex 
:100000000C94E24B0C94034C0C9477D20C94034C5C
:100010000C94034C0C94034C0C94034C0C94034C24
:100020000C94034C0C94034C0C94034C0C94A2D4ED
:100030000C94034C0C94034C0C9468B70C94034C34
:100040000C94034C0C94034C0C94034C0C94034CF4

    No problems registering the USB device in dmesg

    [  381.605671] usb 1-1: new full-speed USB device number 3 using xhci_hcd
[  381.741747] usb 1-1: New USB device found, idVendor=0403, idProduct=6015
[  381.741760] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  381.741764] usb 1-1: Product: FT230X Basic UART
[  381.741768] usb 1-1: Manufacturer: FTDI
[  381.741771] usb 1-1: SerialNumber: DN010NRM
[  382.786824] usbcore: registered new interface driver usbserial
[  382.786843] usbcore: registered new interface driver usbserial_generic
[  382.786856] usbserial: USB Serial support registered for generic
[  382.789628] usbcore: registered new interface driver ftdi_sio
[  382.789644] usbserial: USB Serial support registered for FTDI USB Serial Device
[  382.789671] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
[  382.789698] usb 1-1: Detected FT-X
[  382.789870] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0

    This is run from Ubuntu

    The only success I see is people saying they reflashed it using a AVRMkII https://www.synthetos.com/topics/did-i-blow-up-my-board/

    Which led me to this https://github.com/synthetos/TinyG/wiki/Firmware-Update-Verification-Failure

    which says, basically I need to buy that piece of hardware to be able to use your product 🙁

    Im really not sure what todo from here, did anyone in synthetos get my contact form with my Board Id to let me know if it was part of the problem?

    • This reply was modified 8 years, 6 months ago by dgtlmoon.
    May 2, 2016 at 10:35 am #9643
    cmcgrath5035
    Moderator

    I am not Synthetos, just a Forum lurker/moderator. I do see the requests to the Contact URL, I can’t recall if I saw yours or not. When did you send in your query?

    Some background that might help:
    The thread you referenced that started way back in 2014 had origin in a Lock Bit setting that was blocking flashing of the device, IIRC. Unless you have a very old tinyG, that is not likely your issue.

    In late Dec 2015, a small batch of tinyGs were factory programmed incorrectly (again, fuse or lock bit programming) that made the tinyG overly protective of low VCC voltage, resulting in self destruct that corrupted both the tinyG FW and the bootloader FW. The recent references you post above, about how to use the MKII to reflash, are aimed at that firefight.

    You obviously have a functioning bootloader, based on your terminal logs above.

    What version of SPJS do you have loaded on your Pi2B?

    OK, so you are a linux guy (me openSUSE), I wanted to know your Desktop OS so I could point you down the correct path for bypassing SPJS and using avrdude from the command line. You already figured that out.

    I am a bit stumped
    Your flash log looks OK, except of course for the verification error.

    For the moment, I am fixated on your avrdude version 6.2-5.
    Where did you get that from?

    My openSUSE has avrdude 6.1 in the repositories. Works OK directly from desktop.
    Chilipepper is actually using avrdude 6.0.1 in the SPJS implementation.
    I vaguely recall downloading an avrdude version 6.2.something at one time, which did not work with tinyG. That could be your issue.

    Here is a wild guess as to what may have happened when binary data got sent down as Gcode:
    In addition to the user parameters you see with $$ command, there are other parameters in the EEPROM that are used by tinyG internals. Something in the command stream may have caused tinyG to corrupt EEPROM, then crash. The best way to fix that corruption is to relaod FW, which rebuilds EEPROM parameters as part of the install process.

    I am actually somewhat surprised the bad command stream ever got sent – the ChiliPeppr Gcode widget and SPJS are very Gcode knowledgeable. Hard to predict how your binary file got interpreted.

    See if you can find an avrdude 6.1 for your Ubuntu system and try that

    May 2, 2016 at 11:17 am #9644
    dgtlmoon
    Member

    Thanks for the reply

    So I followed https://github.com/synthetos/TinyG/wiki/TinyG-Updating-Firmware – I’ve tried the packaged Ubuntu avrdude as well as the one mentioned in the wiki

    yeah so i’ve used the Ubuntu one and the one linked to in that article

    dgtlmoon@dgtlmoon-XPS-15-9550:~/workspace/cnc/tinyg/arduino-flash-tools-master/tools_linux_64/avrdude/bin$ ./avrdude -v

avrdude: Version 6.0.1, compiled on Mar  5 2015 at 18:42:02
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

    and the ubuntu one

    $ avrdude -v

avrdude: Version 6.2
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

    But both are giving me the exact same output error, Pi2B running 1.92 latest stable from github

    So yeah i’m lost. I havent received any reply from Synthetos yet

    May 2, 2016 at 11:18 am #9645
    dgtlmoon
    Member

    Request to contact url sent on friday, I included the Id # of the board in that request

    May 2, 2016 at 11:23 am #9646
    dgtlmoon
    Member

    avrdude 6.1 gave the same error at the end. 6.0 6.1 and 6.2 tested 🙂 it’s something with the board

    May 2, 2016 at 2:53 pm #9647
    dgtlmoon
    Member

    I tried flashing just a small image (actually the grbl project hex which I know wont work but I wanted to see if it would pass to rule out any filesize issues) and it still fails

    so it’s something higher up, most likely the bootloader has got itself in a pickle

  • Author
    Posts
Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.