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?
TheNaughtyFantasy Hi, I agree many may avoid serial flashing but thanks to your DFU adventure and file archive upgrading is at least doable, I certainly will give it a go.
One reason I have been more inclined to think large APP (4.4) + Windows 8.1 is causing issues is my cheese and chalk experience loading the same files on Windows 7 VS 8.1
There is no doubt the APP still has to sit inside the boundaries of available/legal flash but I believe version 4.4 - the page 41 version does this. Hopefully DFU 3.45C is golden but I would not be surprised if it took another revision to get it behaving with these very large APP sizes and Windows 8.1/10.
Do you think it’s worth us each PayPal-ing $5-10 to Wildcat to buy the new version?
In regard to the disconnection problems not seen in Windows 10, in Windows 8.I never saw disconnections using the DFU, in fact it almost always seemed like thinks were ok and files would often load and show .RDY but still be not loaded properly (they showed .ERR regularly as well). If I can load Wildcat 4.4 using Windows 7 and everything is working my belief is that code is good. We do need a way of loading large APP’s reliably with Windows 8.1 and 10 and that might involve a new DFU version for something as big as 4.4 - perhaps we should get whoever wrote DFU 3.45C to test it out and see if it is possible. Whatever - your point about the users not re-flashing their DFU is bang on and they will not want to buy new hardware to get the new DFU either so perhaps some clever code that loads as an APP and then updates the DFU might do it, or be impossible for whatever reason. Perhaps SEEED could consider selling the right serial cable setup ready to go to help users update. It may to be a bigger nose bleed for many users to get Windows 7 or XP happening than refresh their DFU if a version that makes it all wonderful is available, perhaps with a script that backs up everything first and allows recovery without skillz.
Awesome. That’s what I thought the Spectrograph function was for. But when I used I had always gotten a vomit of colors and figured it was a different type of spectrograph than what I was hoping for. Anyway, it works. I will need to tinker with this a bit and delve into the manual. 
Thanks!
You’re welcome
This “vomit of colors” is just background noise, which can become prominent if FFT gain is set
high or on LOG or AUTO with no signal. To adjust gain, with menu on CH D, press button 4 to
change menu item, which will access the gain setting. Then use left toggle to change setting. The
user guide simply states “adjust gain the same way as for FFT”, which may not be clear unless you
look that up.
That’s the weird thing…in my device even under windows 7 v4.4 “4-slot” version will not install. Anyways i’m planning to test all of the versions from v4.1 + test versions again with sys 1.62 + sys 1.64 and make a list of what works and what doesn’t.
We could make some paypal crowd funding but it’s better to make a thread first so that we gather more people and so the seeedstudio sees it and hopefully helps us a bit.
TnF Hi, If you have a chance try loading Wildcat 4.4 under SYS 1.62 - changing to 1.62 from SYS 1.64 stopped my apps from crashing when launched. It might not be the same on your device but it could be worth a try.
I have ordered the same 3.3v USB/Serial converter (less than $3 delivered via that auction site). I have plenty of others but they are 5v or the wrong chipset and it’s jut not worth $3 to futz with the issues.
I agree a thread to to get some people/momentum behind getting the latest hardware to Wildcat is the way to go, are there any rules or forum etiquette about how we make that happen?
I did test…major test, took me 1-2 hours to finish. I never had the problems you are describing. If it installs correctly it works on my device. Yes they are pretty cheap. You could used a level converter in your case if you had one lying around. I’m not sure of the donation rules, maybe you are willing to make a thread about it and notify Seeedstudio to see if they can help us out? As long as everyone has paypal i don’t see the problem.
So Wildcat here’s my latest test. All done under Windows 10 with DFU v3.45C which supports Windows 8/8.1/10. SYS 1.64 and HW 2.81
I repeated the test with SYS 1.62, but got the exact damn results. I was going to test SYS 1.63 afterwards but i don’t think it will change anything. Largest file that can be loaded correctly is v4.3 403KB, but always needs a second try to give a RDY file, even though it looks to work correctly on first try. However it seems that the filesize plays role in copying the file over, rest it depends on the program; for example “REDUCED ROM” is 385KB but doesn’t work, it gives .ERR.
It is worth noting that i did multiple installation tries on every problematic .hex. Minimum 3 each, and for v4.4 4-slot over 6 tries. Also when i downgraded my SYS to 1.62 i had to reinstall PAWN again. It will always give me .ERR (even back when i bought my DSO), and needs several tries to work (5-7 tries) even though it will always give .ERR. I wonder why is that since it will always give the same .ERR…
TnF hi again. Seriously, what you describe, especially with SYS 1.62 is exactly my experience with Windows 8.1. Give it a try with XP or 7.
I just tried to load V4.4 from a Win 7 machine with Win 7 displaying the zip archive as a
directory, and it would not work. I suspect you have to extract the files first…
Loading the same hex file as a stand alone with the same Win 7 machine worked just fine.
Could you download the attached file? This is a copy of the HEX file from page 41.
NOTE that this is NOT a RAR archive, but a HEX file renamed with a RAR extension, the forum will not let me upload HEX extensions. RENAME the file from app1.RAR to app1.HEX and see if it will load and work with a Win 7 machine. Thanks
This is the same issue i had with Win 7 and sys 1.62. Anyway i’ll try it again with my new 3.45C DFU and see if there is any difference. Also i always extract the files before copying them. Not directly even though in reality it makes no difference as the extraction takes place in a temp folder. And i checked the hash of the files for any corruption and there is none. Either way i will make a video because it seems i’m not getting through. I will reload the fpga too this time, just in case it has somehow “corrupted” and causes this issue.
EDIT: Just tested it and i’m uploading the video right now.
In the video i initially show hash comparison between the hex.rar file you provided with the original extracted. Completely the same. The environment is obviously WIN 7. I show the 1.62 SYS version and DFU v3.45C. I have re-installed fpga 2.81 prior to the video. As you can see following that, v4.4 “4-slot” fails to install with disconnection of the DFU drive as i’ve described in my previous test list. Following that failure i attempt to install v4.4 “reduced rom and ram”. While the file copies it doesn’t give a RDY file on the first try (even though it has been installed correctly and does work), but it gives on the 2nd try. This is the same thing as i described in the test list above: “Wildcat v4.3 403KB 3-slot NO RDY on first try, although it worked, since it completely copied the hex file over; 2nd try gave RDY file as normal”. Further testing shows this type of error will happen for every proper app that is attempted to be installed after installation of any problematic v4.4 version (the ones that the drive disconnects while copying the file like v4.4 “4-slot version”).
What I need to know is if you have tried to INSTAL the app1.rar file I uploaded…
I know you compared it to the file in the archive, but when you make statements like
“Not directly even though in reality it makes no difference as the extraction takes place
in a temp folder” you are not being very clear about just how you are doing this.
Also, I don’t see any links to the video you uploaded.
Here is the video: https://www.youtube.com/watch?v=Y0BOBghLsGk
It was taking too long to upload, and it was very late so i went to sleep.
Yes i renamed the file you uploaded and tried it out, it’s the same file and of course it gives the same error. Look up the video if you don’t believe me.
And note that the same exact thing happens with both DFU 3.40C + 3.45C, SYS 1.62 + 1.64, WIN 7/8/8.1/10 while as you see other versions work perfectly fine in any of the combinations above. So it’s plain simple to see that the problem resides on your development in this case as we cannot do something to MINIDSO developers to make you a custom DFU if that’s the problem. However if you need me to ask anything about the addresses etc for hw 2.81 on the minidso forum please let me know.
I’ve watched your video, and the results you are getting with the files not loading are
exactly the same I get if I try to load the files directly from the archive without copying
them first to another directory. I am NOT saying you are not copying the files, just that
the RESULTS you are getting are the SAME.
Well, you see, here are the problems I’m faced with:
- You are describing a problem (inability of a properly extracted hex file to load
using Windows 7) that NOBODY ELSE SEEMS TO HAVE.
- For the moment, I could care less about Win 8 or 10. If the latest/greatest from
Microsoft can’t handle copying a simple file to a virtual FAT12 directory, that’s
not MY problem. I have no intentions of obtaining a Win 8 or 10 machine to
test/fix this. Windows 8 has be extensively documented on this forum as having
issues with ALL prior versions as well.
-
The ONLY thing in the way of "my development" or "way I write the program"<br/> as you describe it as contributing to "my failure to fix YOUR problem" that I can<br/> change, is WHERE I put the code in the ROM. Nothing else in the content makes<br/> any difference. We are talking about LOADING the programs here, not running<br/> it. <br/>
4) The ONE THING in common with all the versions you have problems with is
that they are over a certain size. (Do not confuse this with the problem with the
2 first files in Test.zip that went a bit too far in ROM and caused an .ERR file
flag.) This clearly indicates a problem with the loading process, which only the
DFU and the host OS has any control over. Nothing in the content can alter this.
If there was a problem with WHERE the code is put in ROM, which, again is
the ONLY THING I CAN ALTER that makes any difference with all this,
it would not load on ANYONE'S machine.
5) You seem to have some sort of attitude where you are unwilling to acknowledge
any possibility that you may have made a mistake, or overlooked something,
instead of carefully reviewing your actions with the help of others, while at the
same time blatantly blaming someone else for your problem, even in light of
the fact that others are not able to duplicate the issue.
I'm sorry, but I just don't get along with people like that. My health is suffering
right now from the frustration of dealing with this and I don't want to wind up
in the hospital. I will gladly respond to anyone else, but as of now, your posts
will no longer show on my PC. Again, I'm very sorry...
Wildcat Hi. If it is any assistance, when I get the serial adapter I have ordered I will try installing DFU 3.45 and see if it causes loading issues for me. I am absolutely certain the 4.4 code is fine and the problems TnF is seeing are a result of the interaction between Windows and the DFU. The only reason this is of interest to me is if it turns out to be related to DFU 3.45 and if this is the latest shipping version we could let people know what the potential workarounds are.
One thing I was going to ask is, given the copying failure is almost certainly related to the size of the file, is it possible to split the loading into pieces to bring the size of each individual loading session down (APP1, APP2, APP3 etc.). I have no idea if this is possible or practical but thought you might know.
Thanks again for your time, I am really enjoying using the DSO now as it is working much better than I ever anticipated. I have many other high end oscilloscopes and DSOs but this has become my favourite. It was a near useless toy with the stock firmware but is a really practical tool with Wildcat 4.4 loaded. The only thing I miss from larger DSOs is an auto setup feature but that is relatively minor compared to the utility of being able to put it in my pocket and the fact it cost less than a single 10:1 probe for my Tektronix or HP oscilloscopes.
It is not worth stressing too much over these issues, the quality of the firmware and FPGA code the Mini DSO is delivered with is not great and it is a miracle to me you have been able to work around this with 4.4 so effectively. When Windows is added to the picture glitches are inevitable. I think the maxim is ‘If it has Tits, Tires or a Microsoft Sticker there’s gonna be problems’.
- LOL…calm down a bit man. You are far taking things too seriously. Wasn’t i the one offered to help in any way i could? If you have health problems you should be aiming to get well first either way. Don’t get me wrong but from where i’m coming from even the smallest issue is something to be taking care of. It’s not about pride or blaiming someone, so i apologize if it came through with that meaning but the end goal is just improvement.
- Yes that’s the weird thing. Even though we didn’t had more people do some extra tests to compare. Also the 2nd weird thing is that on HW 2.81, SYS 1.62, DFU 3.40C, other people were able to access the DFU drive regularly on win 8/8.1/10 while on my device before updating the DFU i only managed to do it once…
- Couldn’t care less too until i upgraded…plus DFU 3.45C fixes this so i’m not sure why it keeps bothering you…
- Yes that’s why i asked if i can get you memory mappings for HW 2.81…
- See 3)
I remember you.
You also almost banned on kazus.ru forum (with the nickname st0rm53) where you ask about chipp fw. http://kazus.ru/forums/showthread.php?t=100175&page=54
I think that no one do not owe anything to you here.
Pardon for my French.
Yes that was me. I posted a genuine question regarding CHIP’s fw…also asked about wildcat’s back then and made a joke since someone didn’t know what is “a wildcat” while failing to check the link i gave (which was removed by a mod, not my fault)…never came close to getting banned. It seems some people fail to read the whole story and start popping out like smucks…but who i am to judge, right? 