DSO203 GCC APP - Community Edition (2.51+SmTech1.8+Fixes)

Hi, if there are any additional tests or files you want checked I am happy to try. I hope your household health situation is improving.

One slightly odd thing I have noticed is that when the 8MB drive is USB mounted under Windows 8.1 using wildcat 4.3 SYS 1.62 HW 2.81 a subsequent boot will result in a “Configuration file not found” message on the splash screen. If the .WPT file is re-saved then the next boot will show “Loaded configuration file” but subsequent boots go back to the “Configuration file not found” message. The CONF files are not affected and load normally but the .WPT file seems to be messed up by having the drive mounted under Windows 8.1

It’s not a big deal but should probably not be happening.

Sorry to hear about your troubles. I also have HW V2.81, SYS V1.62, DFU V3.40C, but don’t have the same problems. I have WC4.4 (4-slot) installed.



Initially, I thought my DFU was OK on Win10, but later noticed subsequent disconnects/reconnects. I saw a post by Wilkcat of updating the original WC4.4, so I tried to re-install WC4.3 as a prep for installing the updated WC4.4. This failed first try on Win10, as WC4.4 was still installed and working. Moving to my Win7 platform, I installed WC4.3 and then the updated WC4.4. Everything seems to be fine, including the Flash drive.



I think you should stick with SYS V1.62, but was wondering if you tried re-installing the complete set of files, including the V2.81 FPGA files (ADR, BIN). Not sure, but maybe the FPGA file is corrupt. Order of file transfer is import, as pointed out in this link…



<LINK_TEXT text=“https://hifiduino.wordpress.com/2011/04 … art-guide/”>https://hifiduino.wordpress.com/2011/04/30/dso-quad-quick-start-guide/</LINK_TEXT>



Not sure what’s up with Win10, but I did notice from the Device Managers, that there is an additional USB controller device “(USB Root Hub (xHCI)” that doesn’t show on my Win7 machine. Both machines are identical Dell desktop models, so they have identical USB hardware.


Thanks, I lost a very good friend, but it was not unexpected as he was getting along in his

years (as well as I am). Having some trouble dealing with this. Time will help…



It’s frustrating when a version is reported working properly on one device and not on another of

the same HW and SYS/DFU version. Also not sure about the later Windows versions and drive

access issues, there have been reports of problems with these with earlier HW versions as well.

I do have a couple of Win7 machines, but never use them, preferring XP.



Will be getting back into researching all this very shortly, will help keep my mind off things. I

appreciate anyone who is willing to try different versions and memory mappings to help

identify problems, as I at this point only have early HW 2.70 devices.



Fact is, there’s plenty of room to put code in the ROM of these devices, some 350KB of it,

corresponding to a HEX file of about 900KB, but half of it can’t be used because different

versions have FPGA/LOGO files in different places. That is, if we want the program(s) to be

compatible with ALL devices. In other words, if we custom made programs to be used only on

pre-HW V2.81, AND others to be used only for HW V 2.81, we would have much more room

to put code in and could much more easily avoid system areas. As it stands, room is getting

scarce for full compatibility.



Only trouble with different versions for different HW, is if someone inadvertently loaded the

wrong type in their machine, they would wind up disabling the FPGA and/or corrupting the

LOGO screen, so I have been reluctant to go in that direction.


By this you mean it does NOT happen with earlier or other versions of Windows?

Also are you booting the device while the USB cable is attached? Just trying to cover all bases here…

So i think it’s decided. Our DSO’s are incompatible with Windows 8/8.1/10. The only way this can be fixed is for the developers to release a new SYS update i presume like they did with 1.64 which gave MACOS compatibility. So we need to stick with Windows 7 and lower for now.



As for roger4’s device something more serious is going on…The only thing i cannot understand is how borland’s device can install wildcat v4.4 “4-slot” version while i cannot:/ At least i can install the “reduced rom + ram” test version which is supposed to be a “4-slot” version just compiled differently. The only thing i can do to test, is to revert back to 1.62 SYS, and install Wildcat’s v4.3, and then try to update to v4.4:/

Hi. The “Configuration file not found” problem only happens after USB mounting/booting with Windows 8.1, Windows 7 does not seem to cause the same problem. It happens with Windows 8.1 if the USB cable is plugged in when the DSO is switched on or plugged in after it is already running.



I have tried to load Wildcat 4.4 after reloading FPGA and SYS then a working Wildcat 4.3 using Windows 7 but it does not load successfully after many attempts with an error message usually appearing about three quarters of the way through on the progress bar. With 4.4 even if the progress bar completes without an error message 4.4 will not boot, the splash screen freezes and no USB drive is available. Wildcat 4.3 can take two or three attempts, sometimes halting with an error part way through copying. If the DSO is powered off at this point and restarted again in DFU mode the next attempt is usually successful with the progress bar completing and no error message. 4.3 then boots and runs normally with no apparent issues.

Hmm, i’ll try the same and report back. But that’s weird because the 8mb flash drive mounts fine with Windows 10, it’s the DFU drive that has problem with these OS. Have you tried re-formating the 8mb drive in Windows 7?

Hi, yes I reformatted the 8MB drive in Windows 7. It seems to reformat in Windows 8.1 as well but the “Configuration file not found” issue happens with the 8MB volume formatted on either version of Windows but mounted on Windows 8.1.

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 :slight_smile:



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.