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.