Firmware Upload Problem

Home › Forums › TinyG › TinyG Support › Firmware Upload Problem

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • January 13, 2015 at 1:03 pm #7275
    DraytonTom
    Member

    I am having an issue uploading the file tinyg-master-380.08.hex onto my tinyG.
    After figuring out the process of running avrdude (with the full path, rather than “from the directory that contains it”), and creating the folder where Avrdude expects to see avrdude.conf (/usr/local/etc/avrdude.conf).
    I am now faced with the error message:

    avrdude: AVR Part “/dev/tty.usbserial-DA00FNT3” not found.
    Followed by a list of all valid AVR parts as per the .conf file.

    I am using OSX 10.10.1 and have installed the FTDI VCP driver as set out in the instructions previously.

    /dev/tty.usbserial-DA00FNT3 is definitely the correct path for the TinyG and I can connect to it using coolterm.
    I have tried putting the TinyG in bootloader mode, both by hitting the reset button and then hitting enter in Terminal within 3 seconds. And by issuing $boot=1 in coolterm (then disconnecting before sending from Terminal).

    The response from avrdude is the same in all cases. Also if I unplug the TinyG.

    I appreciate this could be being caused by OSX10.10.1, but I have also had a few issues with the TinyG.
    The TinyG came loaded with .97 preloaded but with a number of illegal values in its settings(I found a post somewhere about a batch that had been sent out like this). I reset the values using $defa=1.
    I have had a few issues with my machine when making small movements and as such went through all the parameters in an effort to eliminate the controller.
    When I query the hidden values $ML & $MA return the expected values, but $MS returns “tinyg [mm] err: Unrecognized command: $ms”
    My suspicion is that the original load of the TinyG was corrupted somehow, and this may be contributing to my difficulties uploading the newer firmware.

    Any suggestions, advice or comments would be very welcome.
    One option would be to get hold of a PC and try doing the firmware upgrade from Windows. That would at least rule out OSX 10.10.1 as being the cause.
    Other than that I am out of ideas.
    Cheers
    Tom

    January 13, 2015 at 1:39 pm #7276
    cmcgrath5035
    Moderator

    Tom
    Lets put your avrdude issue aside for the time being – I don’t speak OSX so that might require some research.

    What build of tinyG FW is currently loaded? The Version (0.97) is somewhat meaningless. If you have build 438.02,that is the best there is and I recommend you should stay there.

    What sort of machine do you have?
    When you say

    I have had a few issues with my machine when making small movements and as such went through all the parameters in an effort to eliminate the controller.

    Are you sending GCode or entering individual moves from the command line?
    If sending Gcode, how? CoolTerm or something else.

    Sending #defa=1 will have reset to a base set of parameters.
    Can We assume you then reloaded all the parameters good for your specific machine?

    A listing of your $$ parameter dump, and your Gcode if you are running Gcode, might speed along the discussion.
    Here is a good way to post it:

    January 13, 2015 at 3:21 pm #7278
    chmr
    Member

    Tom,
    I bet you did not use an uppercase -P in front of the device name, that’s what avrdude is complaining about. Uppercase -P specifies the device name / COM port, and lowercase -p specifies the microcontroller part number.
    Good luck!

    January 13, 2015 at 4:47 pm #7279
    DraytonTom
    Member

    Hi guys thanks for the prompt response.

    CMC, apologies its a TinyG v8 Board, firmware build 412.01
    Chmr, you nailed it, thankyou!

    https://www.dropbox.com/sh/yqje28uos84uqtf/AADKtrKtHu38DtDTOttRPNWOa?dl=0

    Yes I did restore machine specific commands after issuing the defa command.

    I have just realised that the firmware I have been trying to upload is an older version.
    According to http://synthetos.github.io/ Master is still 380.08.
    Is it normal to ship TinyG with Edge firmware? Or am I misreading this?
    I have now flashed the firmware quoted as Master, the upshot is that as soon as the TinyG boots, Motor 1-3 LEDs light constantly. I killed power as quickly as possible, will investigate further in the morning.

    A bit more background.
    I have a Routy CNC which is essentially a Shapeoko 2 built using V-Slot.
    I was having an issue with backlash equating to .2mm in both the x and y direction in all parts of the machine bed. I was using a GRBL shield and decided to upgrade to a TinyG, that way I could eliminate the electronics as the cause.
    I had been testing for backlash using a spring gauge and issuing direct gcode commands through coolterm and measuring the discrepancy between theoretical and actual movement(I was concentrating on the x axis only to reduce the number of variables).
    Altering the method of anchoring the belts has made a significant improvement to the problem, but as I had already discovered that the TinyG was shipped with some invalid values (NUM maybe, I didnt record it), I wanted to reflash the firmware for my own piece of mind.

    Thanks again Tom

    January 13, 2015 at 5:23 pm #7281
    DraytonTom
    Member

    PS I have added a text file in the dropbox folder linked above detailing how I got the firmware update to work in OSX10.10.1. Not elegant, but it may be of some use to other Terminal novices such as myself.

    January 13, 2015 at 11:26 pm #7283
    cmcgrath5035
    Moderator

    Tom
    OK, you are now in good shape with avrdude.
    The concept of Master and Edge is a good one, but Master (build 380.08) is now very much behind. Build 438.02 is in process of being “pushed” to Master.

    Depending on the type of Gcode you run, you may see issues with 380.08 that are corrected in 438.02.

    By the way, Motors coming on, then timing out are normal with 412.01.
    You will also see differences here in 438.02, discussed in the settings Wiki at

    Took a quick look at your configs.
    Why would the X and Y distance per revolution ($1tr,$2tr and $4tr) be different?
    Different pulleys, or are you tweaking for most precise moves?
    Also, why $xjm=500 while $yjm=5000; I would start with both = 5000

    I am not exactly sure of what you mean with the term “backlash”.

    January 14, 2015 at 8:34 am #7284
    cmcgrath5035
    Moderator

    Tom

    I had a chance to read your “How to Run avrdude”.
    As I said, I am unfamiliar with OSX and how software runs from zip archives vs ‘installed’.

    If you want to pursue, I suggest you try this from a console window:
    [note: all this based on Linux behavior]

    cd [directory where you have your tinyG.hex file]
    run avrdude with no parameters

    /Applications/Arduino.app/Contents/Resources/Java/
hardware/tools/avr/bin/avrdude

    You should get this

    avrdude
Usage: avrdude [options]
Options:
  -p <partno>                Required. Specify AVR device.
  -b <baudrate>              Override RS-232 baud rate.
  -B <bitclock>              Specify JTAG/STK500v2 bit clock period (us).
  -C <config-file>           Specify location of configuration file.
  -c <programmer>            Specify programmer type.
  -D                         Disable auto erase for flash memory
  -i <delay>                 ISP Clock Delay [in microseconds]
  -P <port>                  Specify connection port.
  -F                         Override invalid signature check.
  -e                         Perform a chip erase.
  -O                         Perform RC oscillator calibration (see AVR053). 
  -U <memtype>:r|w|v:<filename>[:format]
                             Memory operation specification.
                             Multiple -U options are allowed, each request
                             is performed in the order specified.
  -n                         Do not write anything to the device.
  -V                         Do not verify.
  -u                         Disable safemode, default when running from a script.
  -s                         Silent safemode operation, will not ask you if
                             fuses should be changed back.
  -t                         Enter terminal mode.
  -E <exitspec>[,<exitspec>] List programmer exit specifications.
  -x <extended_param>        Pass <extended_param> to programmer.
  -y                         Count # erase cycles in EEPROM.
  -Y <number>                Initialize erase cycle # in EEPROM.
  -v                         Verbose output. -v -v for more.
  -q                         Quell progress output. -q -q for less.
  -l logfile                 Use logfile rather than stderr for diagnostics.
  -?                         Display this usage.

    It shows you how to specify the conf location(-C option)
    Note that you can practice by adding the “-n” option.

    January 14, 2015 at 9:29 am #7285
    DraytonTom
    Member

    Hi CMC

    Thanks once again for your help.
    I found the avrdude options this morning.
    Going to flash 438.02 after I finish this post.
    The firmware settings I posted where at the end of testing the x-axis in isolation(the problem was the same on both x and y axis and so concentrating on eliminating the problem on the axis with a single motor seemed sensible), hence why they are different between x and y.
    The firmware settings don’t reflect ones that I would use to run a job. Normally the x axis settings would be set the same as the y axis.

    I appreciate that Backlash is a much misused term. I am defining it as the error generated whenever the axis changes direction (due to mechanical slack in the system).
    So for example if I moved the machine G21 G90 G0X1 I measured a movement of only .8mm, but a subsequent G21 G90 G0X2 moved the axis the correct distance.
    Axis ended up at 1.8mm.
    Reversing direction G21 G90 G0x1 resulted in the axis only moving .8mm again, so ending up at 1mm a G21 G90 G0X0 moves the correct distance and the axis ends up back at 0.
    Changing the manner in which the belts where anchored at either end of the V-slot reduced this problem. I was under the impression that there was still a lingering problem, but it was a few months ago, and my notes and data dont make much sense to me now.
    I suspect that illegal values I found in the TinyG when I first switched it on induced a form of paranoia and as such the last note I made was “reflash firmware”.
    Hopefully, now I know how to achieve the firmware update, I will be able to make some measurements and everything should be fine.
    Will keep you posted.
    Many Thanks
    Tom

    January 14, 2015 at 11:48 am #7286
    cmcgrath5035
    Moderator

    OK, now understand the backlash discussion.

    In addition to belt tension, another contributor could be motor “relaxation” between commands.
    Depending on your motor power management settings, and the mechanicals of your machine, when the machine is stopped and the motors de-energized, there could be some movement of the system as the motors de-energize, if they were pulling against some tension in the machine.
    I have a bit of this issue with my Xaxis due to some residual forces exerted by a non-ideal drag chain install.

    A test technique might be to run a series of test steps with the motors fully on, then repeat them with the motors de-energized between steps by executing 

    $md
$me

    between each Gcode command. This will de-energize then re-energize all motors.

    Good luck! Have fun!

    • This reply was modified 9 years, 10 months ago by cmcgrath5035.
  • Author
    Posts
Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.