tinyG completely unresponsive

Home › Forums › TinyG › TinyG Support › tinyG completely unresponsive

Tagged: , ,

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • June 6, 2018 at 8:07 am #11009
    JTW
    Member

    Hello group,

    I have used several tinyG’s with great success over the past year, but have stumbled into a problem I can’t seem to solve.

    Here are the circumstances:
    1) Upon power up (24vdc) the blue pwr LED comes on, but no other lights blink or flicker at all.
    2) When sending commands to the tinyG (via putty/plink on RPi3B) the Rx light will flicker, but I never get any reply nor does the Tx light flicker.
    3) If I disconnect the USB cable after establishing a link, the RPi recognizes this and complains… so this all implies that a valid communication link is established between tinyG and RPi.
    4) Pressing the hard reset button on tinyG has absolutely no effect! Nothing. The blue LED does not even blink. I validated the button’s operation with an Ohm meter.
    5) I have tried rebooting/re-powering many times, multiple USB cables, multiple RPis, verified 24vdc at input, 3.4vdc (suspiciously high) at limit switch input headers, and 12vdc at fan output header.

    In short, it seems as if the hardware is working just fine but the firmware somehow got erased(?)

    Any thoughts or solutions?
    Thanks in advance!

    June 6, 2018 at 8:22 am #11010
    Zootalaws
    Member

    The connection between the USB chip and RPi is working, doesn’t mean anything with regards to the rest of the board.

    The power for drivers and power from USB to the main chip are seperate – Without any external power applied, can you talk to it using something like the Arduino IDE com monitor?

    Pressing reset while connected to a Comms app, what happens?

    Have you tried reloading firmware?
    Have you tried running an Atmel diagnostic? The chip is an Atmel ATxmega192A3 – same core as Mega.
    Have you tried talking to it via uart- serial tx/rx? If you don’t have a USB-serial breakout, you can use another arduino as a bridge.

    June 6, 2018 at 8:31 am #11012
    cmcgrath5035
    Moderator

    You might find these schematic pages useful in this discussion
    https://github.com/synthetos/TinyG/blob/a364308c8800ee2fb2227bb83f5d8edce0aae304/hardware/v8schematics/v8d/tinyGv8d%20-%20schematic%20page1.pdf
    and
    https://github.com/synthetos/TinyG/blob/a364308c8800ee2fb2227bb83f5d8edce0aae304/hardware/v8schematics/v8d/tinyGv8d%20-%20schematic%20page2.pdf

    On page 2, the blue LED is connected to +3.3V.
    So, the 24V to 3.3V regulator is working on your board

    On page 1, the Tx and Rx leds are drven by the FTDIdevice (hardware) that terminates the USB link. Not driven by the ucontroller, ATMega.

    The FTDI device is properly terminating the USB link and looks OK to your computer (and the PC driver). Says that the FTDI device is operational, more or less.

    The rest of what you describe says to me that your ATMega is unable to run any firmware, if that firmware exists.
    Something has killed your controller device.
    The FTDI device is a ‘front door’ to the controller.
    The door can see you PC knocking, but no one is home inside the house.

    No info here as to what the cause of that might have been.
    A foreign voltage, something greater than 3V, on an input, for example, typical affects(kills) just that pin or sometimes some physically(not logically) adjacent pins on chip.
    But others could kill everything, for sure.
    Just a wild guess

    June 6, 2018 at 8:39 am #11013
    Zootalaws
    Member

    In addition, if you can talk to it via serial uart (as opposed to USB uart) you should be able to reprogram it and continue to use it via an external interface.

    • This reply was modified 6 years, 3 months ago by Zootalaws.
    June 6, 2018 at 9:19 am #11015
    JTW
    Member

    Thanks all for the prompt responses!

    <<The power for drivers and power from USB to the main chip are seperate – Without any external power applied, can you talk to it using something like the Arduino IDE com monitor?>>

    I have tried powering down the tinyG while a plink connection is active. As soon as the blue pwr LED goes out on the tinyG, the RPi posts a “Bad file descriptor” msg implying that their connection is dependent upon tinyG being powered.

    <<Pressing reset while connected to a Comms app, what happens?>>

    Nothing. It is as if the reset button is inoperable. Blue LED does not even flicker. RPi/plink stay happy although when you look at the device log you can see it disconnected and reconnected.

    <<Have you tried reloading firmware?>>

    No. I was hoping to avoid this as it also appears that the bootloader no longer works. From what I understand, the spindle light should blink upon power up indicating it is in bootloader mode on contemporary v8 boards (which this is), but this does not happen in my case. I only get the blue pwr light, nothing else.

    So unless you see something different, I think it is becoming apparent that the firmware (including bootloader) somehow got wiped from the ATMega chip. I do not have any specific equipment/software for burning firmware to the ATMega chip from scratch… but also have nothing to lose at this point. I will go read up on if this is possible from an RPi, which will likely involve soldering in a header for Rx/Tx and setting up old school serial from my RPi as Zootalaws suggested. I was just hoping for a silver bullet to avoid all this…

    Thanks again for all your input!

    June 8, 2018 at 4:16 pm #11017
    cmcgrath5035
    Moderator

    I

    have tried powering down the tinyG while a plink connection is active. As soon as the blue pwr LED goes out on the tinyG, the RPi posts a “Bad file descriptor” msg implying that their connection is dependent upon tinyG being powered.

    I would expect this. Removing Vmot (24V) also removes power from the FTDI device that terminates USB connection. The FTDI device is not powered from the USB bus.

    Nothing. It is as if the reset button is inoperable. Blue LED does not even flicker. RPi/plink stay happy although when you look at the device log you can see it disconnected and reconnected.

    Per the schematic, Blue LED simply says 3.3v supply is on.
    The response to pushing the reset button would be under control of the bootloader; I agree with you that It sounds like bootloader is gone.

    It is possible that what you report is simply clean flash. (program storage). You might be able to reflash the ATxmega if you had an atmel ICE.
    Or you could try returning the board to Synthetos for a courtesy re-flash.
    I’m not optimistic, you unit sounds deader than most, but might be worth a try

    I don’t think you could do this via TxRx interface. To load new code via that interface you need to be able to trigger the downloader firmware in the ATxmega.
    An ICE can talk directly to memory sub section on a somewhat sane device.

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