Connecting Windows to TinyG2 about g2 HOT 14 CLOSED

What version of Windows? In device manager what show up? Any "yellow" devices?

from g2.

Win7-64. I have more info on the COM port behavior. After programming with bossac (steps below), if I unplug the Programming port and immediately plug into the Native port, Windows doesn't respond at all: no "new USB connection" sound, nothing new in Device Manager, yellow or otherwise.
However, if I leave the Due unplugged for about 30 seconds, then plug into the Native port, Windows immediately makes the new USB connection sound and an Other Device shows up in Device Manager. Then in about 5 seconds, that Other Device auto-converts to a "Bossa Program Port (COM#)" (normal, no yellow).
This behavior is repeatable, including after erasing/reprogramming tinyg2.hex and restarting the computer. That 30 seconds can be less, often as little as 15 seconds, but not 10 seconds. Maybe the Due is fully discharging then? Or maybe some kind of USB port reset?
But, I'm unable to get a response from TinyG2 via either tgfx, Termite, or Putty.

Here is my current draft wiki procedure for programming tinyg2.hex onto the Due via Win7-64 (I will update the G2 Wiki when we're more sure it's correct):

###Step 3 - Program TinyG2 onto the Due

1. Create a new folder wherever you like.
2. Move tinyg2.hex into the new folder.
3. Go to C:\Program Files (x86)\Arduino\hardware\tools and copy the file bossac.exe.
4. Paste bossac.exe into the new folder.
5. With the new folder open, hold the Shift key down, then Right-Click on the background of the new folder window.
6. From the pop-up menu, click on Open command window here. A black Command Window will open with the new folder path and ">" prompt.
7. Plug a USB cable from the computer to the Programming port of the Due (the one closest to the power jack). Make sure there are no shields, programmers, debuggers or other devices plugged into the Due. The Due does not need external power for programming - it will be powered by the USB programming cable.
8. In the black Command Window, next to the ">" prompt:
   a. Type mode and press Enter. COM port info will follow, probably for 2 ports. Your Due is connected to COM#, not COM1. (If more than 2 COM ports show up, find the Due COM port via the Windows Device Manager.)
   b. Type mode com#:1200 (where # is the Due COM port number). Press Enter. (This erases the flash.)
   c. Type bossac -p COM# -U false -i -e -w -v -b tinyg2.hex –R and press Enter. You should see a response like this:

Erase flash
Write 346671 bytes to flash
[==============================] 100% (1355/1355 pages)
Verify 346671 bytes of flash
[==============================] 100% (1355/1355 pages)
Verify successful
Set boot flash true
Device       : ATSAM3X8
Chip ID      : 285e0a60
Version      : v1.1 Dec 15 2010 19:25:04
Address      : 524288
Pages        : 2048
Page Size    : 256 bytes
Total Size   : 512KB
Planes       : 2
Lock Regions : 32
Locked       : none
Security     : false
Boot Flash   : true
CPU reset.

If instead, you see "No device found on COM#": with the board powered, press and hold the erase button for a second, then also press the reset button. Keep them both pressed for another second. Then unplug and replug the Due. Try bossac again.

d. Close the Command Window
9. Now disconnect the Due and wait about 30 seconds (YMMV). Then plug the USB cable into the other port (the Native USB port). Windows should recognize the Due with a sound, and it should appear in the Device Manager Ports as COM#.
10. Connect to the Due/G2 via a terminal emulator or tgfx. [This part doesn’t work for me.]

References:
http://forum.arduino.cc//index.php?topic=142382.0
http://forum.arduino.cc/index.php?topic=132688.0
http://forum.arduino.cc/index.php?topic=141628.0

from g2.

I believe you will the the *.inf “driver" file that I am working on. Once it’s tested and proven a little more I’ll post it and update this ticket.

-Rob

PS: That is great reporting and info, thank you!

from g2.

Thanks, Rob. Good to hear it's helpful. Look forward to the .inf whenever it's ready.

from g2.

Hi Rob & David,

Firstly David, many thanks for your steps. They worked perfectly for me on Win7-64-bit for the flashing process. I see precisely the same 10-30 second issue before Device Manager reports 'Bossa Program Port COM#' for the device connected via its native USB port. I also cannot establish any serial coms with this port and so, like David, have been rather stuck for the last few days.

Rob - how are you getting on with the *.inf file? Is there any way I can assist with the problem to speed things up?

Once we are confident that the end-to-end process is fully working, I am also happy to run the steps through our test boxes here for WinXP, Win7-32-bit and Win8 if that is helpful?

Kind regards

Edward

from g2.

Hi Edward,

I have the .inf file working, but have found issues with the USB stack and
Windows. I'm debugging through that now, and hope to have it fixed this
week.

Thank you for the offer of testing, and I'll happily take you up on that!
I'll post here when it's ready for testing.

Thank you!
-Rob

On Wed, Nov 13, 2013 at 5:26 AM, VeraShackle [email protected]:

Hi Rob & David,

Firstly David, many thanks for your steps. They worked perfectly for me on
Win7-64-bit for the flashing process. I see precisely the same 10-30 second
issue before Device Manager reports 'Bossa Program Port COM#' for the
device connected via its native USB port. I also cannot establish any
serial coms with this port and so, like David, have been rather stuck for
the last few days.

Rob - how are you getting on with the *.inf file? Is there any way I can
assist with the problem to speed things up?

Once we are confident that the end-to-end process is fully working, I am
also happy to run the steps through our test boxes here for WinXP,
Win7-32-bit and Win8 if that is helpful?

Kind regards

Edward

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-28387349
.

from g2.

Hi Edward,
You're very welcome! Glad to hear it worked for you, too.
David

from g2.

Hi Rob,

I hope you don't take this as a nag, but I wondered if you have an update on this? I guess the issue has turned out to be trickier than you first thought? Any feedback would be much appreciated.

Cheers

E

from g2.

No, it's not nagging. ;-)

It has indeed proven more difficult than I first thought. You can look at
the Rob branch and see my progress.

I have a valid inf file (I don't think it's in git, yet) but windows will
simply not talk to the g2. I cannot figure out why, but I'm still digging.

The good news is that I'm finding other bugs in the USB subsystem as I dig
around.

-Rob

On Monday, November 25, 2013, VeraShackle wrote:

Hi Rob,

I hope you don't take this as a nag, but I wondered if you have an update
on this? I guess the issue has turned out to be trickier than you first
thought? Any feedback would be much appreciated.

Cheers

E

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-29191676
.

from g2.

Hi @VeraShackle,

I think I have this ready for testing. Currently you can pull from either the alden or rob branch to get the latest code, and the TinyG2.inf file should be in the top level, ready for installing in Windows.

Please let me know how it goes!
-Rob

from g2.

Hi Rob,

Sorry about the delay but I'm afraid this didn't work straight 'out of the box' for me so I wanted to do a bit of experimenting to give you some decent feedback.

I uninstalled the original Bossa driver and reinstalled using your new inf file. This did not produce any overt errors and Device Manager now lists Bossa Program Port (COMxx) with all the sythetos driver properties as expected.

I reflashed the Due using the latest hex file from github - 18/12/2013 - using David's procedure above.

I can, once again, connect to this com port using either my own code or Coolterm, but again there is still no apparent TinyG communication possible with this port.

Before we go too much further I should just verify that I am not making any stupid mistakes here - my set-up is essentially a direct replacement of the previous Arduino (which I originally successfully used to run a Shapeoko) with the new Due. I am, therefore, expecting the grbl shield (V4) to power the Due from its 24v input - is this correct? Also, when I send commands to the Due I cannot detect any flashes of the RX led - would you expect this?

I have now refurbished a mac book, so I am going to set up the dev environment on that today and make sure that the hardware is all functional through the Mac route so we can eliminate non-windows issues - I'll report back once I've done this.

Cheers

E

PS I'm on holiday now, so should be able to spend a bit more time on this and hopefully give you faster feedback - notwithstanding relative time zones!

from g2.

Hi @VeraShackle,

What hex file from GitHub? I apologize, because I was assuming you were compiling straight from the code. I'll update with a link to a newer hex file shortly.

What shows up in the device manager as the name of the device? Is it showing "TinyGv2," or is "Bossa Program Port"?

Alternatively, if it's "Arduino Due Programming Port," then you need to connect the USB to the other port.

Last option, "Arduino (broken TinyGv2)," means that it's not taking the programming and still showing up as an Arduino.

from g2.

Ok, please visit http://synthetos.github.io/g2/ for links to the binaries. The instructions above say *.hex, but the bossac docs say they want the *.bin file. I have provided both the *.elf and *.bin files, just in case.

ARM compilers use .elf files and then it's stripped to make the *.bin file, so the *.hex part doesn't really make sense in this context anyway.

-Rob

from g2.

Success! Thanks Rob. The correct binary made all the difference ;)

Just to clarify, the file I was using previously was g2/TinyG2/ TinyG2.hex from the master branch of g2 on github.

I appear to be up and running now on Win7 64-bit. I'll test on a Win 8 tablet tomorrow.

Cheers

E

from g2.