Go Down

Topic: Freaduino Mega 2560 and Windows 7 x64 - An Epic Tale of Struggle and Heartache (Read 13207 times) previous topic - next topic

TSUNAMl

After putting in about 17 hours of rage-inducing troubleshooting into my new Freaduino MEGA 2560, I thought I'd share my story.  The story just ended with my little inline blue LED blinking once per second.  And I have no idea how.  So I will start from the beginning, explain what happened, what I did, and perhaps someone can enlighten me, or at the very least, some other poor sap will read this and be able to save a few hours.

Prologue: The setting for this Divine Comedy is America.  It's summer, 2013, the walls still put out 60Hz Alternative Current at ~120 Volts.  A brand new, Freaduino http://www.elecfreaks.com/store/freaduino-mega2560-white-color-p-365.html is removed from it's package, and an accompanying Shield (TFT LCD Mega Shield V 2.2) and TFT LCD is stacked on top of the board.  With Arduino 1.0.5 installed on Windows 7 64-bit edition, our hero connects the board to his PC using only the supplied USB cable (an obnoxious sparkly purple color).  "DuhNAH"  Windows responds in classic fashion and a status bar indicating device found / driving being installed / driver installed successfully flashes in the bottom right corner.  Even more exciting?  The backlight on the TFT LCD is lit, indicating power is being applied through the shield to the LCD.  Right outta the box!  A dream come true.  But sometimes, Dreams have a nasty habit of going bad when you're not looking.

Scene 1 - A quick Timeout
With everything firing on all cylinders, our overly-caffeinated hero copies a fairly large "http://www.elecfreaks.com/wiki/index.php?title=4.3%22_Width_480*272_TFT_LCD_Module" sketch (as they are called) that acts as a video demo for the TFT LCD.  As the progress bar moves in a typical, non-linear fashion, our hero reaches for his cup of joe, and anxiously snaps his head back and forth between the LCD screen and the Arudino IDE console.  Finally, he fixes his gaze on the screen for what seems like an eternity.  Finally taking his eyes off the prize, our hero notices out of his peripheral vision some discolored text in his console.  The programmer has timed out.  The hero tries again, to no avail.  Undeterred, he tries adjusting settings within the IDE, like the programmer of choice, and changing the board from "Arduino 2560 or Mega ADK" to "Arduino UNO".  (After all, he had been successfully programming his other board, an UNO all morning.)  Without any change, our hero returned the settings to their previous (less nonsensical) state.  At a loss, it was time to consult the internet.  What better place to start than the Official Arduino troubleshooting page?  http://www.arduino.cc/en/Guide/Troubleshooting#toc1.  It reads: " The Arduino Uno and Mega 2560 use standard drivers (USB CDC) provided by the operating system to communicate with the ATmega8U2 on the board. Other Arduino boards use FTDI drivers to communicate with the FTDI chip on the board (or in the USB-serial convertor)."

A little further down it seems that Mega 2560's don't always play nice with Win7 x64.  "On Windows 7 (particularly the 64-bit version), you might need to go into the Device Manager and update the drivers for the Uno or Mega 2560. Just right click on the device (the board should be connected to your computer), and point Windows at the appropriate .inf file again. The .inf is in the drivers/ directory of the Arduino software (not in the FTDI USB Drivers sub-directory of it)."

Our hero feels relieved - a known driver problem with a known (and presumably working) fix.  Our hero notes that the instructions are slightly anemic.  The full procedure for switching from the automatically installed FTDI driver to the Windows driver (using the arduino.inf) file is as follows: Enter Device Manager.  Right click on the item shown (in the hero's case - "USB Serial Port (COM20)")  Select "Properties".  Click on the "Driver" Tab.  Click on "Update Driver".  When prompted, select "Browse my computer for driver software".  At the next screen, make sure to click "Let me pick from a list of device drivers on my computer".  The hero feels betrayed that the official Arduino troubleshooting guide left this step out.  Merely browsing to the appropriate folder and choosing next allows Windows to feel vindicated:  "The best driver software for your device is already installed.  Windows has determined the driver software for your device is up to date.  USB Serial Port."  [Close]  Oh, really Windows?  Seems that FTDI version 2.8.30.0 is STILL installed, and I wanted to install the generic driver according to the Arduino's official instructions.  What all future heros need to do is click "Let me pick from a list of device drivers on my computer", followed by the "Have Disk" button.  (The hero performs this step) And how quaint!  Our hero sees a screen he hasn't seen since he was a young lad installing games onto Windows 95.  Fortunately, without a Floppy Drive A:\, our hero Browses to the arduino.inf file located in the "C:\Program Files (x86)\Arduino\drivers" directory.  Opening the arduino.inf file displays a list of Arduino Models.  Scrolling a bit reveals Arduino Mega 2560.  JOY!  Our hero selects it and clicks next.  Windows warns the hero that the driver might not be the correct one for the device.  Yada yada.  Our intrepid hero ignores the warning (YOLO) and continues to install.  The Windows progress bar moves, indicating everything is going as planned.  Our erupts from his supposedly ergonomic desk chair and begins a swagga dance.


TSUNAMl

Scene 2 - Come visit our SOD Farms, we've got all sorts of grasses for sale
IN PARTICULAR, BLUE!  Oh noes!  That's...not good.  A PAGE FAULT IN A NONPAGED AREA occurred and the culprit is...   
usbser.sys   usbser.sys+7528   fffff880`0b675000   fffff880`0b683000   0x0000e000   0x4ce7a66d    11/20/2010 6:43:57 AM   Microsoft® Windows® Operating System   USB Modem Driver   6.1.7601.17514 (win7sp1_rtm.101119-1850)   Microsoft Corporation   C:\Windows\system32\drivers\usbser.sys   

Our hero doesn't natively speak memory addresses and Windows bug codes, but he was able to ascertain that the usbser.sys driver, version 6.1.7601 did something naughty (or had something naughty done to it).  So our hero retries this process, 3, 4, 5, SIX times.  Each time, he tries something slightly different.  First, he removes the LCD and shield, leaving a bare Freaduino Mega2560.  Then, he disables and removes the internal bluetooth controller (as a few random adventurers had indicated this could cause a problem, although they indicated it would be a problem with the IDE software...nevertheless...Then, he tries a less obnoxious USB cable that he knows works.  Finally the hero tries switching the power switch on the Freaduino from 3.3V to 5V even though he assumed that had nothing to do with the problem. No matter what the hero tries he gets the same result.  Remembering Einstein's wisdom, he decides to search for new avenues.  Unfortunately, the FTDI driver will not allow him to program the Mega 2560 and the generic usbser driver causes blue screens.  Fortunately, our hero has a friend nearby with a shiny new MacBook pro (and he's actually not a lame hipster).  The hero's friend agrees to attempt the installation/programming process using the official arduino instructions and OSX.  Unfortunately, the device is never even recognized (at all) by the operating system.  Not as a Network Device or anything else.  After a half hour of OSX troubleshooting our hero gives up.  Feeling lonely and vulnerable, our hero sends out the following transmission to the vendor:

Hi ElecFreaks,

I recently purchased one of your Arduino Mega2560 boards and shield + TFT LCD.  I am unable to program the board.  I have tried Windows 7 x64 and OSX.  I did some research and it seems that Windows 7 automatically installs an FTDI driver for the Mega2560.  It seems the FTDI chip is not correct for the Mega2560 and it causes the programmer to timeout.  This is what i was experiencing.

  I performed the steps to update the driver to the arduino-supplied Windows USB/serial driver.  Unfortunately, where others have had success after performing these steps, I have had no success.  Each time I begin installing the generic windows driver - and selecting Arduino Mega 2560 from the list - my windows blue screens with a page fault error.  Every time.  I have tried removing the shield and TFT LCD and the effect is the same.  When I apply power via USB the board does light up and the backlight of the TFT LCD lights up as well.  The power switch is set to the 3 volt setting.

How can I fix this problem?  Does the board require an external power adapter in addition to the USB power?  Do I need to switch to 5 volts?  Is it possible I have a defective board?  Is there any other driver I could try since there is a know issue with the FTDI driver and installing the arduino supplied driver causes a blue screen? 

Sincerely, [Name Redacted] (but it's the hero)


Within a few hours, the vendor issues the following response to the hero's plea for help.

Dear sir,
Thank you very much for your trust and we are sorry for the inconvenience occurred to you. For your problem, you can try to remove the original drive and download it again, or you can change to another computer to have a try. We hope you to do so to confirm whether the problem is lying the computer or not. Thanks again, and we are looking forward to your reply. Good luck.


Well, it seems the good ol' folks in Shenzen have the following tips: download the drive[r] again and retry, or try another computer.  The hero is alone, and the advice given is fairly standard.  The hero will have to wait until he finds another computer running windows, or try linux.

-=Intermission=- (grab an Ecto Cooler out your Mom's fridge, use the potty, and then strap back in)

TSUNAMl

Scene 3 - Learning to Drive
The hero seeks out other computers to complete  his mission.  He wonders if the state of Windows on his PC is causing usbser to fail, and if a different environment will yield different results.  It's a long shot, but our hero remembers the odds of Han Solo navigating through the asteroid field.  So our hero goes through the same procedure as on his PC - installing Arduino IDE, plugging in the Mega (bare this time) and trying to force Windows to use the correct driver.  As usual, Windows in a blaze of light, installs the FTDI driver and declares the hardware READY TO USE.  With a smirk on his face, the hero gives FTDI another shot.  When he attempts to program the simple blink example, our hero receives the follow error: "stk500_getsync(): not in sync: resp=0x00"  Interesting!  An error different from the standard timeout error.  Our hero's nervous leg syndrome kicks in and he excitedly searches the internet for answers.  According to the LadaAda Help, "Note that it is nearly impossible for anyone to debug this, as there are so many possible issues. Try everything."  http://www.ladyada.net/learn/arduino/help.html  Well then.  Our first turns his gaze towards the Loop-Back test, which had not yet seen.  Before our hero came upon the Loop-Back test instructions stickied to the Arduino forums, he had seen another adventure point out how to do it.  This adventurer only mentioned connecting the TX and RX pins, and not the RST and Ground pins.  With the FTDI driver, and the programmer insisting upon things being backstreet boys and not 'NSYNC, our hero tries typing things into the serial console.  And, yes, we have an echo.  For the first time in hours, our feels like he may crawl out of this E.T. for Atari pit of despair.  Unfortunately, our hero purchased the Freaduino, Shield, and LCD, for purposes slightly more advanced than echoing serial input....and the programmer is still not the right boy band.  Our hero starts to contemplate flashing the firmware, but with little confidence he can verify the correct firmware to install, and/or, the correct procedure, he decides to first do what he set out to do, and that is try the usbser driver on a different windows machine.  Expecting a BSOD, a hero repeats the necessary steps to override the FTDI driver and point windows to the arduino.inf file.  He selects Arduino Mega 2560, button mashes yes/confirm/ok through the warning screens, and waits with his head cocked, lips slightly pursed, and one eyebrow raised, as if to say "let's get this over with already windows."  But alas!  To his surprise, there is NO BLUESCREEN!  Windows alerts the hero that the driver has installed successfully and that a restart is required before the hardware can be used.  Hero: "BOOM HEADSHOT!  If a restart is all you want you can have it!  I'd have parted with 2 wagon wheels, 80 bullets, and Clare, my second born - she's got cholera anyway."  After the restart, our hero fires up Arduino IDE 1.0.5 and starts spamming CTRL+U.  But as it turns out, the proper COM port is not selected.  Upon further inspection, the hero realizes that the Arduino IDE is not allowing the hero to open the COM port.  Nothing ever comes easy to our hero.  But with the drive[r] problem solved, our hero's spirits cannot be damped.

Scene 4 - If you Love something, set it free, if Windows insists on reinstalling it - it's yours.

Our hero quickly opens up Device Manager and contemplates setting up a windows hotkey combo to bring that sumbich up.  Our hero notices that the device, has the yellow exclamation (!) point over it.  A quick check of the properties reveals that "The Device Cannot Start".  At this point the hero starts messing around with Windows Com Ports.  First, he changes the port number from 20 to 2.  No effect.  Our hero reinstalls the usbser driver, restarts, and tries again.  No effect.  Frustrated, our hero registers on arduino.cc in order to post a long-winded rant on the forums, and to warn people to stay away from the Mega 2560, as our hero has come across MANY lost adventurers, some whose problems magically vanished.  Our hero longs to be in such a position.  After registering, our hero noticed the second sticky of the forum indicated how to properly do the Loop-back test.  Our hero remembers how he had successfully done the loop-back test with the FTDI driver that Windows insisted upon by default.  Then, he read the second sentence of the post: "The test proves that the host computer, hardware driver, USB cable, and USB to serial converter are all working."  Hero: "BULL ONEY!"  Our hero reads on, perhaps the loop-back test is different than the simple TX-RX short.  Our hero notices that the official instructions for the loop back test also include forcing the board in a reset state by shorting the reset with ground.  Our hero ponders what difference that would make since he was able to echo messages earlier with only the TX and RX shorted.  In any event, our hero figured he'd give this loop-back test a shot, just so that he could be honest when he ranted in his post how the Loop-back test is a scam!  So first, he "updates" the driver for the device, which allows Windows to reinstall it's favorite driver, the FTDI driver.  At this point, the hero wonders why Arduino made the decision not use FTDI drivers for the Mega, as the hero has had terrible experience with almost every serial to usb converter that WASN'T based on the FTDI chip.  Then our hero remembers a conversation he had with his friend (the one with the MacBook Pro).  Our hero's friend commented on how strange it was that Arduino.cc and all the other adventurers had commented on how the Mega2560 DOESN'T use the FTDI chip when the IC located just about the usb socket on the Freaduino is LABELED "FTDI 1213-C GN480661 FT232RL"  "But the internet said!" was our hero's response to his friend at the time, but he thought about taking a closer look.  Turns out, the FTDI FT232RL is definitely used in USB/Serial applications.  Our hero now thinks that ElecFreaks failed to inform customers that there is a noticeable difference between the Arduino Mega 2560 and the Freaduino Mega 2560.  Namely, that the arduino Mega2560 does not have an FTDI chip and the freaduino does.  In any event, our hero shakes his head to himself realizing that the FTDI driver certainly hasn't been working either - but he decides to try the official loop-back test, right before he drops bombs in forums.

TSUNAMl

Scene 5 - Wait what?

Predictably, the official loop-back test works with the FTDI driver just like the adventurer-supplied loop-back test did.  For kicks, our hero decides to try the Blink example again.  Really, the hero just wanted to see what the programmer error would be this time.  Timeout?  Not in sync?  Too bad, you're just a Deku Scrub?  With a overly-exxagerrated Ctrl+U, our turned away, knowing full well the timeout process takes 30-60 seconds.  As he turns back...wait...could it be?  Does he notice the LED connected to D13 is BLINKING?  AT ONE HERTZ?  Our hero's gaze darts to the IDE console....there's no error message?!?  Upload completed??!  How?  When?  Why????  Our hero snaps out of his trance, and quickly switches to the video demo sketch provided by ElecFreaks.  CTRL+U and....There's stuff on the screen!  The hero begins to draw figure eights on the TFT in color!  "SHUT THE FRONT DOOR!" Exclaims our hero.  

Scene 6 - Repeat-ability

The hero is now on a new mission.  If he dies, his story dies with him, so he it must told to future generations.  He heads to the Installation section of the forums and begins to type.  "In a hole in the ground, there lived a hobbit," his story began.  The second part of his mission was to see if he could now program using the FTDI driver on his original PC.  The one that would blue screen when trying to update the driver to the standard usbser driver.  He plugs the Freaduino Mega 2560 into the original PC, and updates the driver automatically.  Windows, predictably, installs the FTDI driver.  Our hero opens up the Arduino IDE and tries to program the Blink example.  This time, instead of one timeout, the console shows about 8 of them.  Dejected, the hero tries to find out what is different between two laptops, both not of this world, running Windows 7 x64.  On the surface everything seems equal.  Then the hero notices that the FTDI driver on the working Laptop is version 2.8.23.0 updated 2/7/2012.  On the hero's original PC, that refuses to work, the FTDI driver is 2.8.30.0, updated 7/12/2013.  So our hero ventures to FTDI's website to see if he can find an install for version 2.8.23.0 to install on the misbehaving PC.  No luck.  FTDI's only outdated driver for download is 2.8.28 http://www.ftdichip.com/Drivers/VCP.htm  Slightly peeved, our hero decides to try this version before delving further into the mines of Moria for the mithril known as 2.8.23.0.  In order to "update" to the older driver, our hero proceeds with the following steps.  First, he downloads the windows 7 x64 VCP driver http://www.ftdichip.com/Drivers/CDM/CDM%202.08.28%20WHQL%20Certified.zip.  Then he deletes all the files in the  C:\Program Files (x86)\Arduino\drivers\FTDI USB Drivers directory and extras the contents of the downloaded Zip file to that directory.  Our soon-to-be FTDI driver expert then goes through a familiar process - alerting windows that he HAS A DISK and browsing away from A:\ to the \FTDI USB Drivers directory.  From here, our hero chooses "ftdiport.inf" hoping that is the correct inf.  Windows alerts the hero to his successful venture, and the new driver version listed is 2.8.28.0.  Once again, our hero fires up the Arduino IDE and tries to load the Blink example.  Our hero breathes his 1000th sigh of the mission, as the programmer responds with timeouts.  So our hero decided to manually overwrite the driver files that Windows indicated it was using for the device.  By clicking on Driver File Details, our hero learned that 4 files were involved.  The first two were located in the C:\windows\system32\drivers directory.  They are: ftser2k.sys and serenum.sys.  The other two files are located in C:\windows\system32.  The are ftcserco.dll and ftserui2.dll.  Our hero copied all four files and transferred them to the problem PC, and overwrote the files of the same name.  As it turned out, the serenum.sys and ftcserco.dll were the exact same files with the same date and size.  But our hero copied all 4 just to be safe.  This time, as our hero connected the Freaudino Mega 2560, a yellow exclamation point appears, as our sage-like hero half-expected.  Our hero chooses to "update driver" hoping the old (but recently added) drivers will do the trick.  Unfortunately, Windows is very fond of version .30 and at the high slew rates of mosfets switching, decides to download .30 and overwrite all the work our poor hero just accomplished.  Our hero pulls a sneaky one on Windows, however, and yanks the plug on his cable modem so hard he probably just broke it.  And overwrites the files yet AGAIN while repeatedly screaming "WHAT NOW, BILL!??!"  Our hero continued to wrestle with the driver files, trying to emulate the exact environment of the working computer.  But Windows wasn't going down without a fight.  Since the oldest .inf file I could get was for driver version 2.8.20, anytime I replaced the 4 driver files, the inf was somehow overwriting them again with version 2.8.20, or at least, was overwriting the file ftser2k.sys.  So the hero decides to hunt down that file, and replace any and all instances of it with the one that is version 2.08.23.  It appears in a few places:  C:\Windows\System32\DriverStore\FileRepository\ftdiport.inf_amd64_neutral_66f12493ff5adfb9\amd64  

Rolling back to various driver versions utterly failed for our disgraced hero.  Unfortunately, this story ends where it begins, with the hero not having the slightest clue what is wrong with his PC.  Fortunately, he is borrowing another PC which seems stable enough to program the Freaduino Mega 2560.  His main discoveries include that the Freaduino Mega2560 actually uses the FTDI chip despite the Arduino Mega 2560 using a standard windows usbser.sys driver.  In addition, he learned that the loop-back test did not always indicate that the programmer would successfully connect to the board.  Until it did.

CrossRoads

If it helps, I use FTDI chips and or FTDI based modules for all my boards -  mostly to avoid having to program another part on the card.
Driver is 2.8.2.0 from 7/12/2010.
This is from WinVista, I don't know if it works with Win7.
I only recently (last week) connected my first Uno, pointing to the Uno driver for 1.0.5 worked as intended.
Sometimes the old hardware is better?
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

Emiya

Dark dark night trying to reprogram the device, came across a post brother in misfortune.
And even thinking about WinXP. Searching found:
http://forum.arduino.cc/index.php?topic=60316.msg435843#msg435843
Quote
Direct link to setup executable: http://www.ftdichip.com/Drivers/CDM/CDM20814_Setup.exe

I downloaded and put what happened schate  :smiley-surprise:

CrossRoads

Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

craigcurtin

Aah Man - gotta love it when the Asian vendors give you the good oil

If you are prepared to persist i reckon we should be able to get this going

(I have Win7 64-bit on my laptop - IDE 1.04 and Freetronics Ethermega) so close to what you have

First up i would disconnect the board (you have tried another USB cable haven't you ?  XD XD

Get Device manager to show hidden devices (google if you do not know how) and delete all the com ports (and anything else) that is not currently in use

Go into the registry and search for FTDI, USBSER and delete ALL entries for these two

Reboot the machine

Delete the 4 files from the disk that you previously identified

Reboot

Connect your Arduino back to the machine - when it tries to autoinstall let it and see what the result it.

If no good then try doing the manual driver update using the files posted by crossroads and then report back

Craig

macky63

Hi there... Don't know if you already found a way to make things work, but...... I had the same struggle. Then I found an old notebook running XP. Installed Arduino 0023 and used the FTDI drivers that came with the IDE. (I also use an Elecfreaks mega 2560). I could program it and use it to the full extent. Then I decided that I wanted to use my bigger laptop running Windows 7. The mega is part of my 3d printer so the notebook screen was a little too small for prolonged use. I took a VMware XP install and installed it the same way as I did with the notebook. Working flawlessly.....  Please let me know if this helped you ....

craigcurtin

I think we may have lost the OP. Hopefully based on his last post he has not gone out and done something drastic - like slit his wrists ! :smiley-eek-blue: :smiley-eek-blue:

guilloag

I bought the same board Freaduino from elecfreaks, and I had the same problem, of course. I had less luck than previous heroes...the board is still not working. I tryed win xp x86, win 7 x64, 3 usb cables, arduino 022, 023, 1.0.0, 1.0.1, 1.0.5, ftdi drivers: a whole lot of them. I think I have another issue though: when I tested the loopback with serial monitor I got only garbage like if the board was echoing only non-printable chars.
Any help on this? is the FTDI fried?

TSUNAMl

I've never been able to figure out what the problem is.  I continue to use a different computer (running Windows 7 x64) and it works with the FTDI driver.  I have no idea why it doesn't.  I have no updates.  I haven't tried any of the suggestions posted here (yet).  I will update if/when I do.

Thanks for the support!

craigcurtin


I've never been able to figure out what the problem is.  I continue to use a different computer (running Windows 7 x64) and it works with the FTDI driver.  I have no idea why it doesn't.  I have no updates.  I haven't tried any of the suggestions posted here (yet).  I will update if/when I do.

Thanks for the support!


WHEW - The OP is still alive - had us worried !! - Hang in there !

Craig

nickgammon

@TSUNAMI:

Do you mind summarizing your 3,875 word series of posts into a couple of short sentences? You got a Freaduino Mega 2560 and then ... what happened? It didn't work? You couldn't upload stuff? What, exactly?
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics

TSUNAMl

I guess the main takeaways are:

The Freaduino Mega 2560 uses the FTDI chip.  This is different from the Arduino Mega 2560 http://arduino.cc/en/Main/arduinoBoardMega2560

That took a while to sort out.  I should have just grabbed a magnifying glass and read "FTDI" on the IC next to the USB socket.

Otherwise, I get synch errors and timeouts on one Alienware M17x, and on a slightly older model it works.  Both are Windows 7 x64 and have the same version of the IDE and almost the same version of the FTDI driver.

But that's a boring post...

Go Up