@ John - I have uninstalled SDK Pre-release 2 and installed again SDK Pre-release 1 and situation remains the same.
So no device is visible in the FEZ Config. I have also reinstalled bootloader in the G400 PCB including TinyBooter to 4.3.8.0 and again during installing TinyBooter and Firmware 4.3.8.0 in FEZConfig the process ended with error after proper installation of TinyBooter - see the pictures…
Can you show / tell us what the state of the device in device manager looks like, before you do the (failing) upgrade with Fez Config, and also after? Please re-power the device and see if that changes it’s initial behaviour? (yes, I know you’ve shown us the device page from the driver, but I want to see if the device itself changes to a serial device)
(Sorry that my previous pictures were not chronologically placed because I didn’t noticed that my original picture’s self explanation names are not included in the picture list)
@ Brett - I will try to describe installation process.
Following actions are valid after reinstallation to SDK Pre-release 1(but behaviour is similar also after installation of Pre-release 2)
- After pressing button to force the G400 to go to Bootloader installation there is Bossa Program Port (COM5) under COM and LPT .
- After successful Bootloader installation and re-powering there is GHI Bootloader Interface(COM 4) under COM and LPT.
- After installation of TinyBooter in FEZConfig following by error(and after re-powering) there is G400 under Universal Serial Bus(the state is the same also without re-powering in this point)
Now the pictures should be placed chronologically:
- After pressing button to install bootloader
- After bootloader installation
- Driver details after bootloader installation
- FEZConfig Error after TinyBooter installation
- Device manager after TinyBooter installation and following error in FezConfig
It is strange that my first installation of Pre-release 1 on this W10 some months ago (when Pre-release 1 was released) was OK without any issues but now after failing installation of Pre-release .2 it is not even possible to successfully install back Pre-release 1 back.
so I don’t know the answers, but here’s what I would do next.
When you can see a device that registers itself on the GHI driver (the GHI bootloader state), I’d uninstall that device and tick the box to remove the driver files. Then you should hopefully drop into a place where the driver from the Release 1 can be installed and get you back to a place that it should return to the behaviour you saw before.
@ mhstr - Based on your images it looks like the G400 is correctly using the pre-release 1 drivers. Since they worked previously, something likely changed on your computer that broke them. Roughly when did it last work fine? Have you tried to deploy TinyCLR using MFDeploy?
@ John - It is not possible to use MFDeploy for deploying the TinyCLR because also MFDeploy don’t see G400 - simply no device is shown when USB channel is selected so it behaves like FEZConfig.
Difficult to say when it worked last time because normally I use my W7 laptop with Pre-release 1 to develop/maintain our commercial G400 application.
I wanted to test new Pre-release 2 if it is OK and if proved I can install it also on my W7 to release new version for our G400 application based on 4.3.8.1.
So I logically used my second G400 PCB with another laptop(and this is W10 one used by my daughter) to let it run some days and prove it. This W10 worked OK with G400 4.3.8.0 when Pre-Release 1 was introduced last time - so some months ago.
@ mhstr - Have you tested any other G400s on the Windows 10 computer that fails to see this G400?
@ John - I have tested another G400 on that W10 laptop with the same result.
Then I have borrowed another W10 laptop and here the installation was successful without any problems so I have a suspicion that W10 on that problematic laptop is not in “good condition”.
Anyway many thanks for support from your side and also from others.
Hi All:
I am having a rough time updating some Raptor boards to the new Tinybooter.
The boards are at least a year old, maybe 3. The most recent one I am trying shows TinyBooter at 4.3.7.7
From reading the documentation it appears that FEZ Config can update both. I follow the instructions going to G400 Updater,
Rebooting by holding LDR0, LDR1 down while pressing and releasing reset does not put the board in to RS232 mode. So I try the old way and ground pins 8,10 of socket 11 does turn it into a comport (“Bossa Program port (com7)”, This port is using version 1.1.0.0 by Arduino Srl and it is signed.
Trying the G400 updater with Fez Config again after selecting com7, and “G400 updating failed!” appears.
So maybe the loader does not get along with FEZ Config. So I go back to the old way, and look for update.bat, but it is no longer in the firmwares section. So I look farther and see the notes to get the g400-bootloader-installation. I download it, and run Flash Bootloader.bat after making sure that Samba 2.12 is still installed, and that Bossa Program Port is still visible, and enter “7” for the comport number. Then I get "Error in startup script:
Note: I attempted to upload a screen grab as a png file, but it does not show up in the preview??? it starts with “Error h_handle returned zero…”
Any help would be appreciated…
Running Windows 10 (with latest updates)
I did find the log for the update attempt and it shows:
-I- Waiting …
-I- TCL platform : Windows NT
-I- SAM-BA 2.12 on : windows
current connection is \USBserial\COM7, \USBserial\COM7 to be matched
-I- Retrieved arguments from command line :
-I- argv 0 : \USBserial\COM7
-I- argv 1 : at91sam9g15-ek
-I- argv 2 : Bootloader.tcl
To me this indicates that it found the board.
No idea what to do next…
Sam-ba 2.12 is not a great version from my experience for Win8+. Atmel suggest it’s Win7 and earlier, and Sam-ba 3.x for Win8 (they don’t actually link Win10 strangely, but it does seem to work).
1 Like
@ Brett: Thanks for the advice. The batch file is specific for version 2.12, and while I could try to hack the batch file, I think I would rather wait for GHI to respond, and get their take on your comments as others will need this also.
A new version of Sam-ba may present its own hurdles.
Anyway, I do not need to go farther until tomorrow, and it 7:47PM here on Sunday and the sun has just set.
Don’t take this as my wanting to ignore your suggestion - its appreciated!
1 Like
@ rockybooth - Have you restarted your computer after you got that error dialog? We have noticed that sam-ba can get into a corrupt state and show that error until you restart the computer.
@ John:
I rebooted the PC (Win10).
Then I made sure that the Raptor was in comport mode (Bossa Program Port).
Then I ran Flash Bootloader.bat, and it apparently succeeded!
After resetting the device, it shows up in Computer Management as GHI Bootloader interface (com9), so this suggests to me that I need to use FEZ Config.
So I go to FEZ Config. I cannot, via com9, ping, check for update, or run the G400 Updateer.
Any further suggestions?
@ rockybooth - Did you try Advanced > Loader Update > G400?
Once you run “Flash Bootloader.bat”, your G400 is now like the EMX and G120 in that it has a permanent bootloader that never needs to be updated. That bootloader is then used to update TinyBooter and the firmware instead of sam-ba.
I had a very similar problem , but this was on Pre-release-1 using G120. My laptop has a finger print sensor by Validity Sensors, Inc. After I disabled it all my problems disappeared. What I am getting at is, there is a USB device in your laptop is having a conflict with your G400 USB driver. The first thing you need to do is find out what other USB devices on you laptop sharing the same Generic USB Hub. Open the Device Manager and change the view by selecting two View options “Devices by connections” and “Show hidden connections”. See the attached image. As you see, my G120, GHI Bootloader Interface, and Validity Sensor (and few more usb devices) are enumerated under Generic USB HUB. After I disabled the “Validity Sensor”, FEZ Config was able to see G120 as a USB device! I am pretty sure you do have a conflicting USB device on your system and more than likely, that device is not working under W10 either. Search my discussion under “Can not Updat G120E Dev Board using FEZ Config on Windows 10 Pro”
Based on previous post I have also figured out my exactly the same problem with G400 - see history of this thread.
In my case it is “BTH DS3 Device”. After disabling it G400 appears in FEZ Config.
So there is definitely some issue with drivers conflict time to time - not sure if it is related only to W10 or it is general…
1 Like
@ John, @ mhstr, @ bghavami:
Thanks for your responses. It may nave been a USB conflict, I cannot be sure. When I tried to perform the Loader Update from FEZ Config, it worked perfectly, including on several boards. It may be that some other USB device became disconnected unintentionally.
In post #7, I wrote:
"There is a known issue with Windows Insider build 14316 with large downloads"
FYI, it was solved with the build 14332.
1 Like
any news for production release ?