I found this in the english language section of the minidso.com forum. The author appears to be in a support role of some sort.
<LINK_TEXT text=“http://www.minidso.com/forum.php?mod=vi … a=page%3D1”>http://www.minidso.com/forum.php?mod=viewthread&tid=864&extra=page%3D1</LINK_TEXT>
“DFU version number less than V3.42, connection win8.1 may be unstable, Windows 7 is no problem.”
This appears to support the notion that DFU 3.40 and Windows 8.1 do not play nice with each other. It probably applies to earlier versions of the DFU as well.
For those having problems installing/running V4.4 on HW 2.81 this is a version occupying all
4 starting slots, and the rest in what would be slot 5. Code is all in a row, not jumping over
to the second half of the ROM. This is about as “documented” as we can get given the move
of the FPGA to the end of the second half of the ROM, which would indicate the authors
would expect us to instal code all in a row.
Keep in mind this will overwrite anything installed in slot 4. If this proves valuable, another
version can be written to skip over slot 4.
Also keep in mind this is ONLY FOR HW 2.81. The FPGA of earlier devices will be over
written if this is loaded.
We can also try allocating an extra 5KB of RAM. Right now we are only using 60K of 64KB
available, however memory maps show this should be enough.
Hi, Much progress, some embarrassing. I had finally got PAWN running with Wildcat 4.3 and was very happy. You then posted the most recent version of 4.4 recoded as a contiguous install. I tried loading it and it crashed every time sometimes taking 3 minutes or more to give an error message and once locking up Windows with a stuck copying progress bar that would not cancel without a reboot. This seemed odd so I tried reinstalling 4.3 and PAWN 011 with no issues other than it took 3-4 tries to successfully load 4.3. I had been going to the ZIP archive and selecting the file and copying which was working but relied on Windows to behave itself unzipping and copying the file simultaneously so I tried extracting all from the archive and then loading the extracted file to the DFU. Bingo, much faster copying and no errors. Wildcat 4.4 - the version with space for PAWN loaded first time and ran with no problems. PAWN also loaded and ran properly (version 011, I have never been able to load 011B). Windows 8.1 is still not working with extract all and Windows 7 regularly glitches after copying has completed and the volume is unmounted and remounted but the loading is usually successful.
I had normally extracted all before copying files but after the endless repetition of failure with Windows 8.1 and 4.4 become lazy and just clicked on the archive and selected the file. It was working up to 4.3 even with Windows 8.1 so I did not think much about it but it will not work for me with 4.4 no matter what. It seems clear that for whatever reason with these larger files extraction from the archive before copying is essential.
I am sorry it has taken so long and so much of your time for me to figure these things out, hopefully it will help others.
Thanks again for your time and effort.
Wow, 4.4 is really impressive. Much cleaner waveforms and so much easier to interpret. The FFT is hugely improved. Thanks so much!
No problem, I’m just glad you were able to finally make it work. And yes, hopefully will help others.
Let me get this straight, this entire time the update was failing because you were copying the hex file direct from the zip?
I hope this is the case for the other guy too.
That is one thing I have not done and have always unloaded a hex file first onto desktop and then copied onto the dso drive.
Hi. If only it were that simple.
To clarify there were three issues that had confusingly similar results.
Using Windows 8.1 I had loaded without issue at least 10 different APP files including all the Wildcat versions up to and including 4.3 and they just worked with no problems I was aware of. It made no difference I had noticed extracting the file first or copying direct from the archive, remembering this is something done once every few weeks.
Wildcat 4.4 would not load no matter what I tried using Windows 8.1 and I have now found by experiment that there is a size somewhere between Wildcat 4.3 and 4.4 beyond which Windows 8.1 will not successfully copy to the DFU. Windows 8.1 shows no error when this fails and confusingly the DFU often shows the file as .RDY as if it had successfully loaded when it had not. It is easy in hindsight to see the file size was a problem for copying but at the time it looked more like the DFU was not loading the file correctly because of undocumented size constraints on app slots.
After trying to load Wildcat 4.4 the only thing working was the DFU and the splash screen when trying to start the APP was corrupted and no version of the APP would successfully load via Windows 8.1.
After a lot of trying SYS 1.64 fixed the corruption on the splash screen and allowed an early version of the app to load but the software crashed whenever the 8MB drive was mounted which looked like a corrupted config file. For whatever reason SYS 1.64 would also not allow Wildcat 4.4 to load.
I built a Windows 7 box and tried the test app’s Wildcat had but to bypass loading the config file with no success. Went back to 1.62 which would not load under windows 8.1 but loaded successfully with Windows 7 and found that 1.62 allowed the 8MB volume to load.
With Windows 7 I could use all apps up to Wildcat 4.3 and PAWN worked for the first time but no version of 4.4 would run. By this stage I had started downloading a fresh version of the APP for each test in case there was some corruption, then opening the archive and copying to the DFU volume. I did not give it any thought because it had never caused problems before and was supposed to be kosher according to Microsoft. It was only when the contiguous test version of 4.4 was taking over 3 minutes to copy and fail I started thinking something was broken in the copying process rather than the hex parsing and flash write on the DFU side.
It was very confusing going from a full working Wildcat 4.3 with no previous problems to a completely broken setup after loading 4.4 with nothing different other than the version of Wildcat.
Things learnt:
Use Windows 7 or XP to load files.
Extract files before copying to the DFU volume
Don’t use SYS 1.64 if it did not come setup that way, it may cause problems with mounting the 8GB drive. SYS 1.62 works well with windows 7.
Windows 8.1 may corrupt the default config file when mounting the drive.
Windows 7 sometimes glitches when the DFU drive disconnects and reconnects after loading. Manually disconnect and reconnect the USB cable and check if the file is marked .RDY usually it will have loaded successfully, powering off and on can also help.
It is worth sorting out the issues as Wildcat 4.4 is excellent and transforms usability compared to the stock application.
Hi,
First of all I want to say big thanks to Wildcat and all people who help make this great job. The Best Firmware I believe.
And I want to report that I upgrade successfully to 4-slot firmware W4.4 from p.41 on 2.81 DSO. But only on Windows 7 PC.
When I tried to do it at w8 or w10 I either did not get any result, either I erase all and I had to completely reflash all (sys, fpga, etc.) on the W7 PC. Is is so and for another hex files (other versions).
And one question for Wildcat:
How many periods is necessary for the frequency counter in meters? I get result only from 4…5 if I try adjust xpos, and at least 10 for stable.
Thanks
Alexander
You only need one waveform period, starting with a positive alternation, followed by a complete negative.
More included waves will improve accuracy.
NOTE however, if you have “Cursor select mode” on (mode is on if an “X” shows at top in menu below Ch C)
then ONLY what is between the two T cursors will be counted, so it may appear that more waves need to be included.
Toggle mode by holding button 4 for more than 1 1/2 second, notification will show at bottom and “X” at top will
turn on/off. Please see the user manual for more info on this. Both T and V cursors will affect meter readings in
this mode. Together these cursors can be used to select what part of the waveform meters are reading.
Yes, it was turned on 
Thank you!
I don’t believe it can be done but just in case I missed something – Is there a way to plot frequency over time (ie, a histograph?) with Wildcat’s firmware?
It’d be cool if you could take the frequency of some input and represent it as a graph vs time. Sometimes it’s easier to see glitches this way-overshoots and undershoots from a sensor- vs. just looking at the waveforms.
The spectrograph function does this, shift Ch D input to SPEC. Ch A or B must be turned on, with Ch A
having precedence over B. This plots frequency on the vertical axis against time on the horizontal axis,
with changes in color representing the intensity. Change frequency range with the time/div control, which
will also control the horizontal scan speed up to a certain point. Intensity range can be varied with the FFT
sensitivity control (log > auto > manual from 0db to +42 db).
Time span for one screen varies from about a few seconds at the highest scan rates down to perhaps several
minutes for very slow time bases. If device is not triggered with a signal, AUTO timebase mode can be used
to display background.
An amplitude envelope can also be superimposed by pressing center right toggle while menu is on SPEC. See
the user guide for more info.
Thanks Wildcat for the update, i’ll try it out tomorrow. Btw i manage to get us DFU v3.42 which apparently supports Windows 8/8.1/10
<LINK_TEXT text=“http://www.minidso.com/forum.php?mod=vi … 897&extra=”>http://www.minidso.com/forum.php?mod=viewthread&tid=897&extra=</LINK_TEXT>
I’m assuming FTDI usb to serial should work with programming. Guess i should try it out:) Anyone knows if i need to backup the serial/license key too?
Wildcat, just tested this version on my dso, this one copies 3/4 before disconnecting and manages to write some data leading to the attached boot screen. You seem on the right track as the versions before only copied like 2/4 before disconnecting in the middle of the copying operation. Also this version seemed to overwritten PAWN while the v4.4 “3-slot” and “reduced rom + ram” which install fine don’t overwrite PAWN.
edit: open the attachment image in new tab as it does not re-scale properly in the forum
DID IT! I updated my hw v2.81 to DFU v3.45C and activated with my license key! Now the DFU drive works in Windows 10!
Also Wildcat i tested your v4.4 (4-slot version, + v2.81 v4.4 test version) and they still don’t work. “3-slot” version, “reduced rom + ram” + pawn still work perfectly.
I will be making a tutorial on flashing DFU so stay tuned:)
This last post was an attempt to help with possible issues with a properly loaded program. Other than
a verified and fixed issue of the ROM being overwritten past a certain point, it looks to me like all the
problems so far have been with the inability of the OS used to properly load the hex files onto
the DFU as well as problems with formatting the 8MB drive. If the program is not loaded properly,
you can’t expect it to work.
There have been problems with using Windows 8 and later, possibly with hex files above a
certain size. There have been issues with Windows 8 and earlier devices as well. I would suggest
using an earlier version of Windows, and make sure you extract the files from the zip archive
before flashing.
And yes, this last test post will overwrite PAWN, as it was stated “will overwrite slot 4” and
recommend downloading from the archive on page 41. All of the “test” posts are for testing
purpose only.
Look, it seems you are confusing two different problems. DFU drive support in Windows 8/8.1/10 is one problem, which has been now fixed with DFU v3.45C. The second problem is installing your v4.4 "4-slot" version in hw v2.81 devices. This done under XP/7/10 will fail due to how you wrote your program. It has nothing to do with the OS. I wished i had the money to buy you a hw v2.81 so you could develop on but seeedstudio/minidso they should at least send you one for free for your efforts!
edit: Flashing tutorial is up! http://www.seeedstudio.com/forum/viewtopic.php?f=26&t=6186
Hi, I have Hardware 2.81 with MCU Type STM32F103VE Running:
DFU 3.40C
SYS1.62
APP is Wildcat 4.4 from Page 41 and
PAWN ver 0.11
SYS, APP and Pawn can be loaded with no errors using Windows XP or Windows 7
The APP 4.4 stops loading every single time under Windows 8.1
The 4.3 APP can occasionally be loaded successfully under Windows 8.1 but loads every time under Windows 7
My understanding for this combination of 2.81 hardware and 3.40C DFU is the errors are related to the size of the file and Windows 8.1 failing to load to the DFU volume, not the arrangement of APP slots used.
It is possible with a newer DFU that Windows 8.1 might load 4.4 without errors but the DFU 3.40C Window 8.1 problem is one identified by the support team for the authors of the DFU.
I don’t think the errors loading the file are anything to do with Wildcats 4.4 APP other than the size exceeds what ever limit causes loading to fail under Windows 8.1 and DFU’s 3.42 and below. USE Windows 7 and 4.4 loads and runs (either version) remembering the version on page 41 allows space for PAWN.
I have spent days on this, I could be wrong and please do your own tests. If someone had told me before Wildcat 4.4 was available “Only use Windows XP or 7 when loading APP’s and SYS files” I would have 30+ hours of my life back.
I am still very happy because Wildcats 4.4 in my view is well worth the time I spent to get it working, especially if it helps other people avoid the swamp.
Hi, I would not be confident DFU version 3.45C has resolved APP loading issues with Windows 8.1 and 10 until this was tested carefully.
Wildcat 4.4 is the largest APP yet written for this platform and was not available for testing when DFU 3.45C was written. My understanding is it was written to address flakey copying of 2 and 3 slot applications and possibly allow Mac OS to copy files.
The 8MB volume supposedly needed at least SYS 1.64 to work with Mac OS but SYS 1.64 can cause other problems with crashing at launch.
Again I can only test what I have and I agree someone, probably SEEED? should sent Wildcat several units with 2.81 hardware and DFU 3.40C and on a second unit the latest shipping version.
On the last note yes i too believe Wildcat should be sponsored a hw v2.81 unit at least.
Regarding testing, DFU v3.45C has been around for a couple of months already, and did my testing too on Windows 10, and there are no disconnection problems. On the other hand the large .hex app file disconnection issue could be either workaround in the app software by Wildcat or either in the DFU but let’s be honest, how many people would open the device and flash using an RS232 adapter?