MKR Vicor 4000 driver depression

Had already installed the "core" and then tried Tools>Board> and then selecting the MKR Vicor 4000 driver. Doesn't work. I have the board hooked up to my USB and it's powered and blinking (this is new out of the box and I am a now a first time disappointed user) and my PC keeps saying "The folder you specified doesn't contain a compatible software driver for your device. If the folder contains a driver, make sure it is designed to work with Windows for x64-based systems." when trying to select a driver from the six or eight that are in the Arduino sub directory. NONE of them work. No inf file I use works. WTHeckidyHey.
P.S. Never liked Java unless it was in my cup. More control in C++

Hmm.
I didn't have any problem with Vidor drivers. It automatically find in windows 10 x64.

Only reasons to that happen is then they downloaded wrong firmware or you are trying to update wrong device.

They had some problems in first firmware that you need double click the reset button to go bootloader only mode. With that you updated new firmware. Problem was that it crashed during programming or didn't start programming.

I have used arduino 1.8.8 version. I'm not sure was drivers from 1.8.5 what I used earlier for other arduino boards.

Hi max2kow,

Once you install the "SAMD Beta Boards" from the board manager of ArduinoIDE, an appropriate driver for the MKR VIDOR 4000 will be installed here:
C:\Users(Your Login name)\AppData\Local\Arduino15\packages\arduino\hardware\samd_beta\1.6.25\drivers

If the driver is not automatically recognized, you can specify the above driver folder manually.

After your VIDOR 4000 is successfully recognized, you had better update bootloader as Limba mentioned:
https://forum.arduino.cc/index.php?topic=563513.0

I'll start from the top.
1.) I did use the "install the "SAMD Beta Boards" from the board manager of ArduinoIDE". But that still didn't automatically load the right drivers. Everyone keeps saying that but it's not true. I had to manually find the right driver and it worked but only after I tried several baud rates between the desktop's USB baud rate and the actual one on the MKR board (which is never defined because expectation of it working 'automatically" is too high).
I did get it working and it would upload a modified version of "BLINK" with a different flash rate as a test but after loading SUCCESSFULLY it would give me an error even though it was working. This is more than likely caused by the board resetting (as it would normally after a load) It gets a reset and considers the loss of communication an error. Not the most elegant operation.
2.) I didn't load the wrong firmware version (or it wouldn't be working right now) FYI I'm using a Windows Professional 7 desktop.
3.) I'll check the other topics.

I had a try with Windows 7 to see if I could reproduce the issues you experienced. At the end of the Arduino SAMD Beta Boards installation, you are prompted whether you want to install the drivers.

For the first test, I declined the automatic driver installation. I then did a manual driver installation by pointing the Windows driver installation wizard at the drivers subfolder of the Arduino SAMD Beta Boards installation at C:\Users(Your Login name)\AppData\Local\Arduino15\packages\arduino\hardware\samd_beta\1.6.25\drivers. It installed the drivers and I was able to use the my MKR Vidor 4000 board with no problem.

For the second test, I confirmed the automatic driver installation. There were a couple of dialogs where I needed to confirm the installation due to the Windows security settings. After the automatic driver I was able to use the my MKR Vidor 4000 board with no problem.

So from what I can tell, the driver system for MKR Vidor 4000 is working just fine with Windows 7. I also find it encouraging that it's now working fine for you.

max2kow:
I had to manually find the right driver

Are you certain you didn't deny the automatic driver installation when you installed Arduino SAMD Boards?

max2kow:
and it worked but only after I tried several baud rates between the desktop's USB baud rate and the actual one on the MKR board

How did you set the baud rate? Are you talking about setting it via Serial.begin() in your sketch and the baud rate menu in Serial Monitor?

Well.... First, I did not deny the IDE setup to load the drivers automatically. I wouldn't have improvised and said "Eh, I'll just do it manually later." because who knows where they're coming from. So even though I had it uploading and working, I took your advice and went to the directory you mentioned and manually tried to update to the Arduino driver. When I tried it just said "Windows has determined that your drivers are up to date." And it still had the usbser.sys driver I already had there. And by the way, that driver is 32K large while the Arduino driver you specified is only 8K. Not that it's important but maybe the Windows one is more all encompassing? So after it wouldn't accept that Arduino driver as better/newer I decided to uninstall the driver and then manually again upload the Arduino driver. I did so and it accepted it. I did a Tools>Get Board Info (which is my way of testing communication) and it returned all info. Not sure if this is refreshed every time? That being ok, I then tried to compile a program (Blink) I tried before and upload it. It compiled and then died upon upload giving me this info:

An error occurred while uploading the sketch
processing.app.debug.RunnerException
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:152)
at cc.arduino.UploaderUtils.upload(UploaderUtils.java:77)
at processing.app.SketchController.upload(SketchController.java:732)
at processing.app.SketchController.exportApplet(SketchController.java:703)
at processing.app.Editor$UploadHandler.run(Editor.java:2070)
at java.lang.Thread.run(Thread.java:748)
Caused by: processing.app.SerialException: Error touching serial port 'COM4'.
at processing.app.Serial.touchForCDCReset(Serial.java:107)
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:136)
... 5 more
Caused by: jssc.SerialPortException: Port name - COM4; Method name - openPort(); Exception type - Port busy.
at jssc.SerialPort.openPort(SerialPort.java:164)
at processing.app.Serial.touchForCDCReset(Serial.java:101)
... 6 more
Exception in thread "Thread-48" java.util.ConcurrentModificationException
at java.util.LinkedList$LLSpliterator.forEachRemaining(LinkedList.java:1239)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at cc.arduino.contributions.libraries.LibrariesIndexer.rescanLibraries(LibrariesIndexer.java:167)
at cc.arduino.contributions.libraries.LibrariesIndexer.setLibrariesFolders(LibrariesIndexer.java:120)
at processing.app.BaseNoGui.onBoardOrPortChange(BaseNoGui.java:678)
at processing.app.Base.onBoardOrPortChange(Base.java:1317)
at processing.app.Editor$UploadHandler.run(Editor.java:2106)
at java.lang.Thread.run(Thread.java:748)

Take from it what you may, but it's not working. So... I uninstalled the Arduino driver and once again tried to install the Windows driver. Guess what? It wouldn't take it like it did before. Uh, I'd like to go forward, not backward in progress. Now I don't know if it was mentioned before but I am not using the cloud. This is a desktop install so I don't know if that causes something different. So now my only option was to try different baud rates. To answer your second question, I didn't want to fool with the board's baud rate because that could cause all kinds of trouble and I also wasn't aware of the syntax to set the baud rate. So I went to the Device Manager in Windows and tried every reasonable baud rate. 19,200 seemed to work. Although many others kinda worked. So I went to try that again. By the way, every time I clicked on the Compile and Upload button, the green status bar would go full and freeze. Since this doesn't have a "Stop" button I could only click on the Verify button to stop/clear/reset it. I finally got to 115,200 baud and it was able to upload my program and operate. THE FIRST TIME. As before, it's still giving me this:

SAM-BA operation failed
An error occurred while uploading the sketch

[=========== ] 37% (64/172 pages)
[====================== ] 74% (128/172 pages)
[==============================] 100% (172/172 pages)
done in 0.086 seconds
CPU reset.

But I'm assuming it's because when the reset happens automatically the communication makes it look like an error. You know, someone should really post the default baud of the board to be clear. So, back to not working. This is not a plug and play, it's a plug and beat it over the head with a sledge hammer. At least before it was working every time. It's sure not working now.

max2kow:
I am not using the cloud. This is a desktop install so I don't know if that causes something different.

I gathered that from the previous information in this thread, and so all my tests were with the desktop IDE, not Arduino Web Editor.

max2kow:
So I went to the Device Manager in Windows and tried every reasonable baud rate. 19,200 seemed to work. Although many others kinda worked. So I went to try that again. By the way, every time I clicked on the Compile and Upload button, the green status bar would go full and freeze. Since this doesn't have a "Stop" button I could only click on the Verify button to stop/clear/reset it. I finally got to 115,200 baud and it was able to upload my program and operate. THE FIRST TIME.

I've seen that baud rate option in Device Manager, but never messed with it. This is the first time in 6 years of being on the Arduino forum every day that I've seen someone talk about needing to use that to upload to their board. It certainly isn't an ordinary course of affairs. The port of my MKR Vidor 4000 is set to 9600 in Device Manager and I can upload without any problems.

max2kow:
You know, someone should really post the default baud of the board to be clear.

If the need to set the baud rate was at all common, I would agree. However, I don't think that is at all a common thing, so it would not be useful information to add to the documentation.

max2kow:
By the way, every time I clicked on the Compile and Upload button, the green status bar would go full and freeze

After compiling a sketch, Arduino IDE tries soft-reset to put the VIDOR 4000 into bootloader mode.
But in my environment, the soft-reset for bootloader mode often failes and it stops like this:

PORTS {COM3, COM4, COM7, } / {COM3, COM4, COM7, } => {}
PORTS {COM3, COM4, COM7, } / {COM3, COM4, COM7, } => {}
PORTS {COM3, COM4, COM7, } / {COM3, COM4, COM7, } => {}
PORTS {COM3, COM4, COM7, } / {COM3, COM4, COM7, } => {}
PORTS {COM3, COM4, COM7, } / {COM3, COM4, COM7, } => {}
Uploading using selected port: COM7
C:\Users\minatsu\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.7.0-arduino3/bossac.exe -i -d --port=COM7 -I -U true -i -e -w C:\Users\(myname)\AppData\Local\Temp\arduino_build_500812/USBBlaster_AvalonMM_Gdev.ino.bin -R

When the above situation occurs,

  1. I double-click the reset button on the VIDOR 4000 to put it into bootloader mode manually,
  2. choose a serial port for bootloader from Arduino IDE menu and
  3. click the upload button on the Arduino IDE again.
    It always succeeds, but after that Arduino IDE cannot open an appropriate serial communication port because I changed it to the bootloader port at Step 2, thus I choose the serial port again.

This is my usual operation.

This is my follow up to not getting the right driver and still having trouble with my MKR Vicor 4000. After much frustration, I decided the best path would be to uninstall the IDE and then reload it. I want to say at this point when I did that there was no place to check or uncheck (deny/undeny) or any additional link to upload the automatic driver installation. So I'm not sure what someone else is loading but I'm loading Version 1.8.9 for Windows.
Still didn't work and it kept selecting the C:\Windows\System32\Drivers\usbser.sys driver, wouldn't let me select/update/change to the C:\Users[UserName]\AppData\Local\Arduino15\packages\arduino\hardware\samd_beta\1.6.25\drivers directory.
I uninstalled again and did a search through the Windows Registry. There were many references and KEYS left behind of Arduino that kept pointing to the usbser.sys and also settings that said Arduino was installed [Installed(1) rather than 0] which will keep setting it up the same way and not allow you to change. Naughty, naughty. When you write an uninstall program, you have to take the KEYS with you.

The perfect example is if you use the registry editor (REGEDIT from the search programs prompt) and go to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class{4D36E978-E978-11CE-BFC1-08002BE10318}\0002 you'll see:

DriverDesc REG_SZ Arduino MKR Vidor 4000
DriverVersion REG_SZ 1.4.0.0
ProviderName REG_SZ Ardino AG (www.arduino.cc)

Or/and just do a search on "Arduino" and you'll see a lot of things. And you'll find the cases where "Installed" status is set to 1 rather than 0. Not what uninstall is supposed to do. I haven't gone through the time consuming process of deleting and changing all the keys I found, because there's a lot. I think that might either fix or at least help it. But if you installed the right driver somehow and you even did an uninstall you may never be able to get my condition unless you change the KEYS. WARNING: To all the pseudo engineers out there, NEVER play with the registry unless you are well versed on what you are doing. You could crash your machine and have to wipe it clean to fix it. You can go there and do a Control-F and find these things but don't change anything.
I hope that Arduino cleans up their act and removes keys they put in the registry during the next version of their uninstall. This assures a clean install. If I find the exact cause of this kind of problem I'll post, otherwise anyone else with the knowledge/experience have any insight, please let me know. This is what I did when I used to work for other people, find the glitch no one else could, so I'll let you know.

max2kow:
I decided the best path would be to uninstall the IDE and then reload it. I want to say at this point when I did that there was no place to check or uncheck (deny/undeny) or any additional link to upload the automatic driver installation. So I'm not sure what someone else is loading but I'm loading Version 1.8.9 for Windows.

The automatic driver installation for the MKR Vidor 4000 is offered when you install Arduino SAMD Beta Boards via Boards Manager (Tools > Board > Boards Manager), not when you install the Arduino IDE.

Well, I wouldn't have known that because it's not doing that for me in EITHER case. As I stated, even after uninstalling everything that option doesn't "automatically" come up at all in either case. And the Tools>Board: already has MKR Vicor 4000 after it even after a fresh install after uninstall. Clicking on Tools>Board: and selecting MKR doesn't change the driver. Clicking on Tools>Board>Boards Manager just shows all the add ons available, where in my case the two shown as installed are:
Arduino AVR Boards Built-In by Arduino version 1.6.23
and
Arduino SAMD Beta Boards (32-bits ARM Cotex-M0+) by Arduino Version 1.6.25

Still, the driver is unchangable. It still defaults to Windows' usbser.sys. Do you understand now?

As a matter of fact, if I go to the
Arduino SAMD Beta Boards (32-bits ARM Cotex-M0+) by Arduino Version 1.6.25 box and click on Remove, it won't remove it. Something is far more than you think.

max2kow:
Well, I wouldn't have known that because it's not doing that for me in EITHER case.

Well, now you know.

max2kow:
the Tools>Board: already has MKR Vicor 4000 after it even after a fresh install after uninstall.

That's because Arduino SAMD Beta Boards is not removed when you uninstall the Arduino IDE.

FYI, the name is Vidor, not "Vicor".

max2kow:
if I go to the
Arduino SAMD Beta Boards (32-bits ARM Cotex-M0+) by Arduino Version 1.6.25 box and click on Remove, it won't remove it.

I just did a test with Windows 7 and I can't reproduce that issue either. Try it on another computer to see whether these issues you're having are isolated to only one system.

Some notes from my tests.
OS: Win 10 64bit
CPU: i7-6700k

This uses usbser.sys from microsoft (10.0.17134.1 (winbuild. 160101.0800)) for Vidor bootloader.

Only sketch where I had to use double click reset was uploading after usbblaster sketch because it uses different usb drivers. So need to go bootloader mode.

If I remeber right I had very bad hassle before I updated my bootloader. I was giving weird errors etc and fails upload sketch. Com port was in device list but upload fails most of time.

Have you run sketch from Examples/SAMD_UpdateBootloader/UpdateBootloader (under MKR Vidor examples)
This will upload update program to Vidor. In next boot you have to open serial console and press "y" for updating bootloader.

Reminder for others:
Don't use esd foam when prototyping or use pullup for reset.

Edit:
Does comport in device manager say "Arduino MKR Vidor 4000 bootloader (COMxx)"?
These upload error what you posted look pretty familiar. Did you update the bootloader?
Factory bootloader is failing bad

Thanks Limba, finally someone with tech knowledge. I will look into that and report back. After a lot of frustration, I stepped away from Arduino boards for 5 days to take care of other projects. Oh, and I should mention it since someone (pert) brought it up, that the reason I call Vidor "Vicor" is because Vidor is a boy's name meaning "happy". (look it up) And I'm not happy. Vicor on the other hand means conqueror which, in a self-deprecating way, means I will conqueror it or it will conqueror me. You're also right that using the FPGA takes something other than novice knowledge. I've extensively used Cyclone FPGAs in designs and this one seems wasted. A serial memory would have been better (and less board space) leaving more IO pins to go to the connectors with anything. Either the buffered SAMD pins or anything out of that beautiful FPGA state machine alleviating processing time from the SAMD. Or better yet a nice connector full of additional IO. Thanks again. I'll check your suggestions.

Hi Limba, that worked! You da man! (Or possibly da woman!) Wow, Arduino should really update boards before they send them out or at least send notifications. Thanks again! I'll start calling it Vidor again. Ha!

Yeah I'm a man.

Maybe I didn't clearly say in my frist reply that factory image of bootloader is buggy as hell :slight_smile:

I think SDRAM is ok if you plan sometime use NIOS II or LM32 from lattice with big program size or have other use for internal ram blocks. Next bigger (U484) is 19x19 mm and it would be hassle to route to that small space but that would allow 32 bit ddr and more LVDS lines.

I think the product page still says wrong intenal ram as kB not kbits.