I take it that you don’t have a problem in loading the various versions with the DFU? In other
words, when copying the HEX files to the DFU the volume shuts down and reappears with
with a .RDY file with all the versions you have tried?
If that’s the case, and now even earlier versions fail to start, I suspect you may have a corrupted
WPT file. If you can boot with any other program that will let you access the drive (for example
the original APP file that came with the device), access the 8MB drive and delete the WPT file
(after making a backup copy!). Then after loading any of the new versions, see if the program
then starts. If so, and you have created any of the additional configs with CFG files, you can
just load one of these and save that as a #0 boot up file to restore saved calibration settings.
If that still doesn’t work, make note of any messages on the start screen which could help
resolve the problem (with the WPT file deleted, there should be a message that states “config
file not found”).
I don’t believe this is a SYS version issue, at this point I would avoid loading a different one.
However, it would help to hear from anyone else if they have successfully used V4.4 with SYS 1.62
to verify this. Keep in mind that the DFU versions also generally update as well along with the SYS
versions, and these are NOT available.
If you want to try SYS 1.64 it’s available here:
<LINK_TEXT text=“http://www.minidso.com/forum.php?mod=vi … a=page%3D1”>http://www.minidso.com/forum.php?mod=viewthread&tid=67&extra=page%3D1</LINK_TEXT>
If should be compatible with HW 2.81. Not familiar with any “/B” versions though.
The problems reported so far have been only with flashing the program using SYS 1.64
(actually with the DFU version that comes with it, not SYS 1.64 itself) and this is what the “fixed”
version fixes. There also seems there may be some issues accessing the DFU drive with Windows 10,
will have to wait on more feedback with this.
If deleting the WPT file fixes the problem you should probably reformat the 8MB drive (with 4096 sectors).
Save whatever you can from the drive first as a backup… Also, there may be some issues in using a
WPT file that was generated from a later version, so it’s best to always save these before upgrading so
the can be restored if going back to a previous version.
Everything working fine on my end still. Love the invert. Thanks again, Wildcat. You are awesome.
That said, I wonder what DFU version is the latest. My DSO quad was purchased about a month ago and it comes in a metal (not plastic) housing/case.
In my case, it was the DFU that was causing compatibility problems with Wildcat’s latest firmware… I have the DFU 3.45c. And I do have sys 1.62 though I did start out with sys 1.64. Maybe I should reinstall the 1.64 and see if I have problems then?
No, Windows 10 has nothing to do with this problem. It’s just that in Windows 10 you cannot access the DFU disk; it shows as empty even though the DFU driver installs correctly. What i think the problem is with Windows 10 is some incompatibility with the file system the DFU disk is formatted, because it takes like half a minute to access and then gives the “no disk found whatever” error message. Windows 7 on the same system works perfect and i’ve used that to upgrade your app along the sys from v1.62 to v1.64 (also 1.64"B" is the same one so sorry for the confusion)
Then if the “4 slot” version seems to has a problem installing at least on my device. This explains why PAWN was not overwrited too during the failed installation. Note that i do not get an .ERR file. While installing the normal “4 slot” version it would copy to the DFU disk about 3/4 from total, then the DFU disk disappears and breaks the copy operation, while not showing back again until i disconnect the DSO203 from usb port and connect it again. This does not happen with the “3 slot” version. Tested both with 1.62 and 1.64 sys. The only reason i updated to 1.64 sys was to check if it provided Windows 10 compatibility of the DFU disk (which it does not).
Hmm. I am running DFU v3.40C not v3.45C. Should i upgrade to V3.45C and re-test then? Also you state the “reduced ROM and RAM” version is still a “5 slot version” even though it is generally a reduced size. However like i mentioned in my previous post it does install fine!
So:
Wildcat v4.4 - “4 slot version” 424KB - fails installation
Wildcat v4.4 - “3 slot version” 271KB - installs fine
TEST1 - REDUCED RAM - 422KB - fails installation
TEST1 - REDUCED ROM - 385KB - fails installation
TEST1 - REDUCED ROM AND RAM - 383KB - installs fine
TEST2 - 424KB - fails installation
“fails installation” = DFU disk disconnects while copying the .hex file and DOESN’T come back with .ERR
So PAWN doesn’t have to do anything with this issue
Yes that is correct (regarding MAC compatibility). I did look at the properties of the drive. Like i said even though the driver installed shows correct and working, if i bring up the format dialog it shows as “Unknown capacity” and 0 bytes total size. Also if i try to access it as mentioned above it will show “Please insert a disk into Removable Disk (E:).” In addition the long accessing times of the disk are consistent with Windows behaviour accessing damaged disks from my experience. In this case however is an incompatibility with Windows 10 not actual damage to the DFU partition. Only thing i can think off is to update the DFU version and check again. But the question is, does anyone else been able to access the DFU disk with Windows 10 (also 8/8.1 i think has the same issue)?.
Finally as stated above in this reply, i had SYS 1.62 and updated to 1.64 (1.64 = 1.64B). Windows 10 incompatibility is a different problem than the problem with installing the app as it is done under Windows 7 where it is possible to access the DFU disk.
EDIT: And now i noticed…There are no DFU update files! DAMN! So i’m stuck with DFU v3.40C!
Hi again. Yes the DFU seems to be working, all the versions do convert to .RDY normally but all then hang at boot. Unfortunately it does not go past the splash screen with any version of the app I can find. The USB Drive shows as unrecognised by Windows 8.1 with the following message “The last USB device you connected to this computer malfunctioned, and Windows does not recognize it.”
I cannot at this stage find a way to mount the 8MB drive to delete the WPT file. Any suggestions gratefully accepted.
Ok I eventually tried version 2.51 and that would boot. I backed up and deleted the WPT file and reformatted the 8MB drive. It now boots with 4.3 or 4.4 but many things are not working normally, if I hold button 1 there is no CHART appearing and no beeps after the first one. It’s almost 5am here so I have to quit for the night, thanks for your help.
Are you pressing down long enough? The long press is longer now than what it was before, from what I’ve read.
I have tried for 60 seconds and it still does not come up.
DFU version is 3.40C
You can if you want to, this would help verify compatibility and hopefully help others that are having problems.
Thanks for your help in testing the various versions.
What else is not working? Are you starting the program without a config file? (On the boot screen, this would be indicated
but a “config file not found” message.) I have not tried booting the latest version without a config file, will check into it in
to see if that causes any issues.
If you are loading the config file (perhaps the previous save copied back to the drive?) then the problem could be with
this config file.
Borland stated he is using the 424KB version on his SYS 1.62/DFU 3.40C device successfully so I don’t believe it’s
a version issue. The one thing in common with the versions you are having issues with seems to be that the files are
larger than 383KB. You stated you did a “Windows properties” on the DFU with Win10 and it came up with unknown.
What does Win 7 report as the size of the drive? If the drive reports as not being large enough to hold the file
that could be why it’s not working.
From what I can tell, the DFU is a virtual disk made up of the RAM, which is 512KB minus the bootloader (DFU),
which, for example in the early versions left about 503 or so KB. It may be the new DFUs use more code, or
look at what is already installed and for some reason this leaves less room on the drive, so there just isn’t enough
room to fit the file.
An example of the changes is with this “limit” they have that prevents code from being loaded past with DFU 3.45C.
This is a good thing in my opinion, prevents corrupting the FPGA. Note though, that this is not related to the size
of the file being loaded, but to how far the file loads it’s code in ROM.
I would be really curious to see the size of the DFU as reported by Windows (or any other suitable means).
I have tried with and without a WPT file it loads the file if it is present but either way still no CHART as well as other menus not working. I also retried ver 4.3 and 4.4 but after loading 4.4 just now it locked up again and now will not start even with 2.51. Is there a way of starting from scratch and reinstalling the other components of the system as whatever happened when I loaded 4.4 for the first time seems to have caused bigger problems. It was working with no issues on earlier versions.
The DFU for hardware 2.81, Sys 1.62, DFU 3.40C reports in Windows 8.1 as 2,064,384 bytes with 1024 used, formatted FAT and showing as a removable drive.
Here’s what I have with Windows 10…
Is anyone else having issues such as this with V4.4 after a successful flash (meaning returning a .RDY file)? The only other issues so far have been with the flash process itself (with SYS 1.64/DFU v3.14 detecting ROM being loaded at too high an address, and issues with Windows not transferring the HEX file properly and shutting the volume down prematurely.
As far as “starting over”, you can reload the SYS file, as well as the FPGA, and reformat the 8MB drive once you can boot
up a APP file. At this point, you can’t reload the DFU, as it’s not available. Furthermore, this needs to be done internally
by accessing the processor directly. The FPGA usually will report an error on boot if it has been overwritten, so it’s
probably OK.
The 2 posts showing the DFU size as 2MB doesn’t make much sense to me, and this MAY be the cause of some of the
problems. For example, on my device, Windows shows the DFU drive as 503MB and completely empty. I have successfully loaded up to 500MB on this, with an attempt at 512 showing an “not enough room” error. This is with DFU 3.10 and WinXP, however…
Unless the processor is accessing some other volume I’m not aware of, I can’t imagine where Windows came up with this
2MB DFU drive. Unfortunately, since I don’t have one of these new devices, will have to rely on feedback from other users,
but will see what I can find out.
Also just checked, and no problems with booting up V4.4 without a config file, so I would suggest to anyone having problems to first run it that way.
Here’s what I have with Windows XP…
Hello again. Windows 7 reports the DFU drive as 1.96mb…that’s the same as Borland reports. That’s is also the reason why i don’t get an error of not having enough space to copy the over 400kb versions in the first place. Also i manage to uninstall the DFU driver under Windows 10, and managed to have the DFU drive come up! (again with 1.96mb size). However after i disconnect the cable and connected it again it seems to come back to the same problem. I wasn’t able to reproduce this (probably need a pc restart), but while it was working i saw 5 hidden folders with naming like “$SYSTEM.ERR” or something similar:/ Note that this Windows 10 system i run has been upgraded from Windows 7 so it might be using wrong drivers of some sort. I tried updating the drivers but couldn’t find any newer version. It reports driver version: 10.0.10240.16384. Something really weird is going on… Btw wildcat didn’t the HW2.81 came with 2mb DFU flash?
The STM processor only has 512KB of ROM memory, in all versions I have seen used in the Quad. The most these processors can have is 1MB. The only other memory on the processor is a maximum of 64KB of RAM. The only other memory on the device is the either 2MB external flash chip of the earlier devices or the 8MB chip of the HW2.72 and later but these are not used to flash programs. So I don’t know where the DFU/Windows is coming up with this 2MB drive.
Without having the device itself or some better info from the factory (the earlier Quads had fairly well detailed memory maps) I can only guess as to what is going on.
On my machines, including on a Win7 PC, the reported DFU size is 503MB, completely empty (this is with earlier hardware and DFU V3.12).
It may be interesting to look at these drives with a low level file system tool such as Directory Snoop. On my devices,
this reports the same 503KB capacity with FAT 12 as the file system and 512 byte sectors.
The drivers used to read the DFU should be the same generic volume drivers used to access the 8MB FAT 12 drive. There is nothing special about these, FAT 12 was originally used by Microsoft with MS DOS and floppy drives.
Hi, as a suggestion is it possible to make a version of the APP solely for recovery purposes that does not load the WPT file. It would not need to provide any functionality beyond mounting the 8MB drive to allow removing the WPT file and formatting the partition. At present if the WPT file is corrupted it can take a ridiculous amount of faffing around to try and find a configuration and app that will boot and mount the partition on a device with 2.81 hardware. There is also a significant risk of bricking the device by corrupting the DFU image while trying out the various options. I am still unable to mount the 8MB drive to delete my freshly corrupted WPT file but fortunately at this point the DFU is still working.
Another possibility might be to set a semaphore after the APP launches successfully and check this next time the APP is started, ignoring the WPT file if the previous launch was not successful. At present the mechanism for writing files still seems a bit brittle and recovering from these issues is not at all obvious or straightforward.
Thanks for your help with this, it is greatly appreciated.
[attachment=0]dfu.png[/attachment]
See? This is how HW 2.81 units DFU shows in Windows. Also here is the problem with how incompatible versions fail to install:
https://youtu.be/WclOeQJkrys
The video was supposed to be longer but I run out of memory in my phone. As you see when you install a problematic file the DFU partition remains non-accessible until you power off the DSO and power it up back again to DFU mode. After that you can re-try to install whatever you want.
Also Borland what HW version you’ve got?
I also grabbed any data could with Directory snoop. Anything not shown is 0 data (I checked):
http://imgur.com/a/zWxNe
Click on the photos to see them in actual size.
Finally I experience no problems with your app versions that I can install. It seems the rest of users here with malfunctioning apps is somehow related to being able to install the same problematic apps of which my device doesn’t let me install:/