Hi,
I'm trying to load a new firmware version. I'm following the steps from the tutorial (https://www.openacousticdevices.info/flashing), and when I reach step 5 (Enable Programming mode), after the LEDs stop flashing, a Windows pop-up letting me know a new device has been plugged appears, but it fails to install any drivers for the device, and I cannot continue de process (no new COM ports appear).
I use Windows 7 Pro. I've googled for drivers but been unable to find any.
Is there any drive/program or procedure that should be run/installed before attempting to flash?
Many thanks in advance,
We've updated the flash app to address the issues that you found. The new version, and updated instructions, should be up early next week. Alex
Only the standard warning that Windows can't verify the publisher - just need to click "Install this driver anyway" and no problem.
Yes you are right. I'd assumed that the boot loader wouldn't actually do anything until it received some data to write but sending 'u' or 'd' seems to either erase something or set a flag that shows that the firmware is valid so it doesn't start running the firmware. That's straightforward to fix. Thanks for debugging this.
Did you have any issues with warning about unsigned drivers when using the .inf file from Silicon Labs?
Thanks Alex - I actually managed to fix the devices just before your reply!
Coming fresh to the problem this morning I noticed that the devices were appearing in Device Manager as normal when the pins were shorted with the device connected to USB, even though there was no LED activity. "Flash -i" then returned the correct serial numbers and "Flash -c" the CRC "EB6C" in each case, as last night. Flashing version 1.1.0 firmware was successful in both devices, returning the correct CRC: 4393.
I saved a record of last night's command prompt activity so I can now see what happened and can replicate the issue.
Initially I entered the port name in lower case: "flash -i com4" which returned: "ERROR: Could not find port". I re-entered in upper case but mistakenly typed the -i option after the port name: "flash COM4 -i" which is a request to flash the firmware with the contents of the non-existent file "-i". The app correctly returned "ERROR: Could not open file" but had already trashed the existing firmware. Unfortunately when I tested the second device I inadvertently restored the incorrect command line again - with the option at the end - so the same issue repeated.
Clearly there is an issue with the flash application, such that it does not check that the file can be opened before starting the update process. The app sends the instruction 'u' to the device before calling "sendXMODEM", where it attempts to open the file - is this the problem that trashes the firmware?
Anyway both my devices are now working normally so my panic is over!
To enter the boot loader mode the processor needs to wake up from reset with the two terminal shorted together. In normal use when it is running our software when you switch to CUSTOM without configuring the device it is going to sleep and waking up all the time, flashing the LED, so just holding a paper clip on the two terminal is sufficient to enter boot loader mode.
If the software gets corrupted you can still enter boot loader mode by shorting the pins together and then powering up. The easiest way to do this is to remove the batteries, hold a paperclip on the contacts, and then plug in the USB cable. A bit fiddly but not too bad. The device should then be in boot loader mode and you can install the correct software.
I'll try to reproduce the issue you had. It does occur when I use flash on a Mac and it should all be the same on Windows (it's the same code) but something might be strange there as it shouldn't be possible to brick the device.
Alex
Windows 7 already has the VCOM driver - usbser.sys - and just requires the correct .inf file to connect the driver to the device. The file EFM32-Cdc.inf from github did the trick and also works on Windows XP (although the AudioMoth software won't run on that platform).
However I now have a big problem. My own AudioMoth was given to me and I was not sure whether it had up-to-date firmware. You have previously posted instructions (in the thread "How to check firmware version?" with a link describing how to use flash.exe to return the serial number and flash CRC (github.com/OpenAcousticDevices/Flash). I followed the instructions in this link with the following results:
"flash -i COM4" returned "Serial Number:" followed by blank
"flash -c COM4" returned "Flash CRC: EB6C".
(Note that I did NOT run flash.exe with any other options apart from -i & -c and did not attempt to flash a new firmware).
After disconnecting the AudioMoth from the PC the device appears to have been bricked and will no longer power up either from batteries or USB.
Unfortunately, I didn't immediately replace the batteries so I didn't initially notice the issue and, since the reported CRC didn't correspond to any of the currently available releases, for comparison I also attempted to read the CRC of a second AudioMoth that has been loaned to me, and which I was sure contained up-to-date firmware. Flash.exe returned exactly the same results and that device too now appears to be bricked!
Is it possible for me to resurrect the two devices?
Hi,
There is some discussion of Windows 7 USB CDC issues in this thread:
https://www.silabs.com/community/mcu/32-bit/forum.topic.html/usb_cdc_and_virtualc-xz9d
One solution proposed there is to install Ubuntu in a virtual machine which seems a little like overkill. They also describe installing the driver manually and point to this repository as containing the appropriate EFM32-Cdc.inf file.
https://github.com/EnergyMicro/EFM32LG_DK3650/tree/master/examples/usbdcdc
The readme file here says:
Manually direct Windows to look for drivers in the directory where you have your copy of the "EFM32-Cdc.inf" file. This can be done with the new device
"Wizard" which might pop up after device insertion, or you can open "Device
Manager", left click on the new device and select "Update Driver Software...". Some versions of Windows wont allow you to install unsigned drivers. If you suspect this, reboot the PC and repeatedly push F8 during boot until the boot menu appears. Select the "Disable Driver Signature Enforcement" option. You should now be able to install an unsigned driver.
You can download the EFM32-Cdc.inf file directly from here:
https://www.dropbox.com/s/qn81uhcug6v3ydb/EFM32-Cdc.inf?dl=0
I read that Windows 7 is still used on 40% of Windows devices. Is there a particular reason why you didn't upgrade to Windows 10?
Alex
Sorry I don't have a Windows 7 device to try it out on. I was told that the FTDI driver was the same, and this seemed a straightforward route since FTDI drivers are very widely used, but on looking at the documentation that they are the same.
The easiest route would be to try to get Simplicity Studio to install it for you. There instructions are at the top of page 4 in the Silicon Labs application note.
https://www.silabs.com/documents/public/application-notes/an0042-efm32-usb-uart-bootloader.pdf
It says:
"If using a Windows host and you want to use the USB CDC virtual UART, a USB CDC device driver must be installed. This is most easily done by opening the Device Manager, right-clicking on the device and selecting [Update Driver Software...]. Do a manual install and browse to the location of the SiLabs-CDC.inf file."
This is a USB CDC driver which seems to be installed automatically by all later versions of Windows. There are lots of forum posts elsewhere about installing the driver manually on Windows 7 but it doesn't seem so straightforward. I'll see if I can install Windows 7 on an old machine and work out a process that works reliably.
We realise that re-flashing the device is a bit tricky on Windows 7 (on later Windows it seems more straightforward and Linux has the drivers pre-installed in most builds) and I'm currently writing a USB MSD boot loader so that the firmware can be dragged onto the device like a USB stick, to make this aspect easier.
Once you get the driver installed, re-flashing the firmware with the application is reasonably straightforward. It's how the factory program them in the first place and it works reliably.
You can also post us the devices and we can reflash them for you.
Alex - was that just a wild guess? The Windows VCP driver from this link is not recognized by Windows-7 - I tried both the standard download and the setup executable and both fail to install. Similarly the legacy XP driver fails to be recognized under XP.
These drivers are described as specific to FTDI devices - why can't you just provide the SiLabs drivers for the EFM32?
Hi, You should be able to download a driver from here - https://www.ftdichip.com/Drivers/VCP.htm. It should be either the 32-bit or 64-bit Windows version at the top of the list. Alex
Not exactly a helpful response, Alex! So-called "Simplicity" Studio is anything but and I had no success finding a driver in that morass of incomprehensible gibberish either! Is there an available Windows-7 driver and if so where can we obtain it?
Thanks for the feedback. It seems that Windows 7 doesn't come with the driver installed for some reason.
Thanks Alex, sorry for the late feedback. We've tried with three different machines runnig Windows 7 an the problem seems to persist. The workaround we've found is to install the Simplicity Studio and from there install the drivers for the board.
Best regards,
Hi, Windows should install the driver for you automatically but it has a problem doing this sometimes. What does it say when it fails to load the driver what does it actually say in the window? Some people have reported that it works after restarting Windows and trying again. Alex