Bare Xmega configuration help

Home › Forums › TinyG › TinyG Support › Bare Xmega configuration help

Tagged: 

Viewing 13 posts - 1 through 13 (of 13 total)
  • Author
    Posts
  • June 16, 2015 at 12:30 pm #7837
    macsrevenge
    Member

    I managed to fry the xmega on my tinyg board, I have checked everything else and it seems to have survived. Have dropped in a replacement atxmega192a3u and am struggling to get it configured correctly (I am a novice with ISP programming).

    Using Atmel studio 6 (windows 8.1) and an AVRISPMkII I have been able to set the fuses and upload the bootloader but fail to get a flashing red light. I have also been able to upload the tinyg.hex (370 and 440) and can get the startup communications via coolterm and have the board correctly identified by chillipeppr but cannot return communications (the receive led flashes briefly on the board but no action occurs.

    Is this a problem with the EEPROM being empty of config settings or something more basic than that?

    thanks in advance.

    June 16, 2015 at 8:00 pm #7840
    cmcgrath5035
    Moderator

    It is not real clear what you mean by

    ) and can get the startup communications via coolterm and have the board correctly identified by chillipeppr but cannot return communications (the receive led flashes briefly on the board but no action occurs.

    What does coolterm show on connection?

    Do you get tinyG> prompts?

    EEPROM should be populated by the tinyG at first boot, I guess, the “factory defaults” would be copied into the clean EEPROM (unless this somehow occurs during the flashing process).
    Parameters have to be set for the USB interface to work.

    Do you get any response to a $, $$ or ? comand from CoolTerm?

    June 17, 2015 at 1:48 am #7841
    macsrevenge
    Member

    Hi Cmcgrath, thanks for the reply. Sorry if I was not clear in the last post.

    In coolterm, on connection and board reset I will get:

    {“r”:{“fv”:0.970,”fb”:440.14,”hp”:1,”hv”:8,”id”:”5U1316-KLZ”,”msg”:”SYSTEM READY”},”f”:[1,0,0,8197]}

    but then nothing, no response other than a brief flash of D4 to any command including $,$$ and ?.

    chillipepper will connect via the serial port json server and identify the board firmware but any commands just build up in the buffer.

    I thought there would be some kind of EEPROM initialisation on first run. Just leaves me scratching my head on where to go now.

    June 17, 2015 at 7:08 am #7843
    cmcgrath5035
    Moderator

    Did you send a rest command (ctl-x) or hit the rest button to get that response in Coolterm?
    The parameters reported , “fv”:0.970,”fb”:440.14,”hp”:1,”hv”:8,”id”:”5U1316-KLZ”, are from the parameter set , but may be read from FLASH rather than EEPROM.

    I do know that when you use the bootloader to update your tinyG FW (e.g. 380.xy to 440.yz), the EEPROM gets rewritten with the new FW’s set of defaults, I assumed on first boot of the new FW.

    I have no experience with the MKII method of programming.

    Do you still not get the flashing LED when you manually reboot to tinyG? That of course is not correct behavior.

    When you say that Chilipeppr identifies the board FW, are you doing a manual reset of tinyG or is the CP requesting the board info?

    I’m sort of wondering if the receive path of the on-board ftdi device is bad, but transmit is good

    • This reply was modified 9 years, 5 months ago by cmcgrath5035.
    June 17, 2015 at 7:28 am #7845
    macsrevenge
    Member

    Thanks, certainly some things to try out. Should clarify the reset was a hardware reset using the button on the board, the firmware is being uplaoded via the ISP header rather than via the usb/bootloader route (which is unavailable to me due to the bootloader issues). CP shows the current firmware in a popup at the top of the window when it connects to the com port.

    Will physically check the traces between the ftdi chip and the micro tonight. Though the last micro was damaged it still functioned (just ran at 120 degrees) and the comms worked at this point so presuming the ftdi chip itself is OK.

    Thanks again for the input.

    June 17, 2015 at 8:27 am #7847
    cmcgrath5035
    Moderator

    Does this apply to Chilipeppr activity as well as CoolTerm

    Should clarify the reset was a hardware reset using the button on the board,

    As you may know, when SPJS first connects to tinyG, it sends a number of command queries to get synced up with tinyG. You can see this in the CP Serial port Console window (lower left of GUI).
    A number of commands are queued up, then get checkmark as they execute. One of those commands will return $fb and that will be displayed in the TinyG Widget.

    You should not have to manually reset tinyG after starting up CP. The fact that SPJS sees and is able to connect to the ftdi device seems to indicate that at least the USB side of ftdi is working OK.

    If you HAVE TO reset tinyG to get any response in CP, that would seem to support my theory that the path from ftdi into the Xmega has an issue.
    CP may be able to use the autonomous status broadcast (that you see in CoolTerm) to populate the $fb field, but will appear hung, as you report, if the other start up commands are not being heard and responded to.

    II understand you are flashing via ISP, I’m not much help there.
    Unclear if there are operational side effects of bootloader nor running properly.

    June 17, 2015 at 4:17 pm #7849
    macsrevenge
    Member

    If in doubt go back to the basics. dry solder joint at pin 18 (Tx) on the replacement Xmega. Now get communication both ways in coolterm. Can hopefully get some configuration stuff done now. Thanks a million for your help.

    June 17, 2015 at 6:37 pm #7855
    cmcgrath5035
    Moderator

    Hey, 1 0ut of 144 ain’t bad…. 🙂

    You really should pursue fixing the bootloader.

    I emailed Riley to stop by, I can’t offer much help there.

    June 18, 2015 at 7:35 am #7859
    cmcgrath5035
    Moderator

    I assume you followed the bootloader programming process here:

    If unsuccessful, you could send it back to Synthetos for reprogramming.

    July 15, 2015 at 5:01 pm #8013
    macsrevenge
    Member

    Managed to get everything up and running again, bootloader and all. Thanks again for the help.

    July 15, 2015 at 5:35 pm #8015
    cmcgrath5035
    Moderator

    Might be helpful for others – can you point to the Wiki (or other) information you used to get bootloader going again?

    Great success, BTW

    July 19, 2015 at 4:21 pm #8066
    macsrevenge
    Member

    I must admit I just went back and followed the official TinyG wiki page. It flashed no problem using Atmel studio 6 via an AVRISP MkII. Not sure what the initial difficulties were caused by. Have encountered a new problem but may be best to put that in a new thread.

    July 20, 2015 at 9:11 am #8073
    cmcgrath5035
    Moderator

    Good news, thanks for confirmation that wiki works

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