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:/
As for Windows 10… I managed to get the DFU disk to appear correctly again:
And here’s what I found in the disk (note in Windows 7 it is completely empty!)(click to see full-res pic):
I tried again Wildcat’s v4.4 “4 slot version”. It copies successfully in the disk, but it just stays there…I even tried the “3 slot version” and the DSO doesn’t do anything…
And again, I couldn’t get the DFU disk to display correctly after I disconnected it/powered it off/etc (tried everything). It seems I need to restart Windows 10 to get it to show again (but I need to test this before to know for sure).
What I noticed though is as soon as you insert the usb cable while in DFU mode, it will go into 3-4 connect-disconnect modes, and I can see for a split second that windows 10 reads the name of the disk correctly, but then eventually fails and things it doesn’t contain any disk.
Anyone knows what the heck is going on here?!?!?
The 4th slot is kept open in the device in all versions that load in slot 1. So any program
such as PAWN, which only uses slot 4 can be loaded, then accessed by holding button 4
while turning the device on. You will then be able to access your drive.
The 8MB drive MUST be formatted with 4096 byte per sector for it to operate properly, on any
of the devices that have an 8MB drive and to be used with any program. This is best done
on a Windows machine making sure you can access the byte per sector adjustment. The earlier
2 MB drives are formatted with 512 bytes per sector.
The config file possibly got corrupted because of an improper byte/sector setting, this has been an issue
with the 8MB drives from the past, simply reformatting will not fix the issue unless this is done
correctly. Once this is fixed there should be no issues with the config files, these are CRC checked
before the program loads the settings, and if found to be corrupted, will NOT load. What happens is
that the file read operation itself fails, loading improper data, causing the program to malfunction.
Keep in mind that loading a config file written with a later version of the program should be avoided.
Think I’ve got a pretty good idea.
The DFU volume info is recognized properly…
First of all, I don’t think these DFU “volumes” really exist. These are just fabricated information
meant to make Windows (or whatever compatible OS being accessed) believe they are a
valid FAT12 directory and make the host OS send the file over to it. Once the DFU code
receives this, it operates as a ROM programmer, and loads the streamed data into proper
place on the ROM. So they can be written to represent any size at all.
The ability to parse out HEX files shows why they are the size they are, and why 2MB is needed.
In the early devices, only 256KB was officially recognized, leaving 128KB for programs. When
loading a HEX file, approx 3X the room is needed (each byte is a 2 byte hex character, +
overhead for the addresses). So 512 was chosen to cover 128 x 3.
With the advent of 512KB ROM in HW2.81, this needed to be expanded to approx 350KB x 3
which is a bit over 1MB, so 2MB had to be chosen.
Also instituted with the later devices, appears to be some safeguards to prevent code from
overwriting important info. In such a case, it appears that the ROM loading stops, the volume
unmounts (such as with the generation of a RDY “file”) and some error sounding file name
is then created in a remounted volume. Apparently, different versions of Windows may react
to this differently, as a volume dissapearing while in write mode, before the write is finished
could certainly “confuse” things.
In any event, the DFU drives are working as they are intended, with different versions of Windows
loading errors in possibly somewhat different ways. What we need to know now, is just what
constitutes areas of the ROM we need to keep away from. Before these latest “safeguarding”
DFU versions, programmers relied on known information as to where the bootloader, system,
program area(s) and the various apps from different programmers, FPGA and LOGO reside,
as well as some common sense areas such as the first 16KB past 256K where, on a true 256KB
device, ROM loads could “roll over” and possibly come back and wipe out the DFU, and stay
away from these, not to forget that on later devices, these appear at different places, so for
true compatibility, BOTH areas have to be avoided.
More info from the manufacturer would certainly be warranted, after all if these devices are MEANT
to have programs written for them, we need to know where to put the code…
In the mean time, all we can do is trial and error. So far with the help of wotsac, I have identified
one point, as I have described in earlier posts, and the latest posted V4.4 version in the archive stops
well short of this.
Hi, thanks for the reply. Unfortunately, whatever has happened with my firmware PAWN is not launching in slot 4 and I have no way I can figure out of deleting the WPT file or reformatting the 8MB drive. I have tried every combination I could to get an application launched and access the 8MB drive with no success. The second time I loaded 4.4 has resulted in the DFU apparently working but no way I can find of loading applications. Sys files can still be changed as I can swap between 1.62 and 1.64.
I am more a user of the device than a developer and have neither the knowledge or the experience to write code for it. I have spent 2 days trying to recover the device and have tried and failed. I do still think a mini version of Wildcat that mounts the drive might be a solution.
Thanks again for your help.
I can take an early version of my program and disable the config file load on boot. Just give me a day or so,
right now I am having serious medical issues in my household I have to deal with.
All the file access routines are handled by the SYS, however, if the drive is so messed up that reading
it locks up the device, that should work.
There should not be anything you cannot recover from as long as the DFU is OK, if it generates
a RDY file after loading, it should be OK. Hopefully you can gain access to the drive, but as soon
as you do, you need to format it with 4096 byte sectors, I suspect this is the source of much
of your problems.
Sorry to hear of the medical issues in the household, I hope whoever is unwell feels better soon. Nothing urgent about the cut down version, it is only my own impatience to recover the device.
In regard to the formatting of the 8GB volume with 4096 byte sectors, I have done this every time I have had access to remove the WPT file. While I am sure it is necessary doing so has not prevented other problems from occurring.
Thanks for your time and advice.
Some progress. I built a Windows 7 box and was able to confirm similar results as was reported by naughtyfantasy.
Copying the file fails part way through with an error for the recent larger app’s like 4.4 where with the same file there is no error shown in Windows 8.1 but the file does not load successfully either.
I found using Windows 7 my success rate loading files via the DFU was very much higher and I was able to get wildcat 3.3 running under Sys 1.64 DFU 3.40C Hardware 2.81 with the exception being the 8MB drive. The splash screen shows “reload parameter from disk” just before the scope appears and starts running but connecting the USB to a PC running Windows 7 or 8.1 caused the application to freeze immediately, it also freezes on the splash screen if a USB is connected. Otherwise 3.3 seems to be running normally. DFU is working as expected except the volume does not seem to disconnect after the file is successfully loaded via Windows 7 or 8.1 but unmounting and remounting the volume shows the file renamed to .RDY
From what I can see Windows 8.1 could be a bit dangerous to use with the DFU, It can look like everything is going well when it reality it is a bucket of warm excrement.
I have not worked out how to access the 8MB drive. It seems it is so munted that trying to mount it crashes the system and yet I am able to go through the motions of saving in wildcat 3.3 without locking up. If there is any way to erase or reformat the drive without mounting it that might be a solution. Any advice would be greatly appreciated.
Not sure how you would format a drive without mounting it, the only suggestions I can make
would be to try different means such as Gparted or WinXP. Even if you can only format it with smaller
byte/sector numbers, or unknown byte/sectors, perhaps a successful format with another
utility will let Win7 reformat with 4096 bytes.
thenaughtyfantasy reported this version in the “TEST1” zip file installed ok, can you confirm this?
“TEST1 - REDUCED ROM AND RAM - 383KB - installs fine”
The following is in reference to your previous post, will upload it anyway in case you need it:
Included are 2 versions, an early one, V3.4 using only 2 slots and the latest V4.4. Both have had their
boot config load disabled. The boot WPT and other CFG files can still be manually saved/recalled.
Also included is a drive image utility, provided by Bobtidey and JPA. Once the disk access issues are
resolved, this can be loaded in slot 4 and will save a drive image of your DFU, SYS, and first part
of the ROM. this can be used later on to recover the device in case the DFU becomes damaged, and
should also restore your license code. Note this recovery, if ever needed would need to be done
with a (free) STM utility and a USB to serial converter connected to a header on the circuit board.
Note also that Alterbios and certain variations of PAWN may instal an alternate SYS file as well as
updated file access functions as a fix for the faulty factory file functions on earlier devices (with 2MB
drives and SYS prior to V1.60) , these should not be necessary for devices with the 8MB drives and
sys 1.60 and later, but not sure how these would work if loaded on these later devices. The boot screen
should show what’s loaded.
Hi, thanks for the test files. I did some more experimenting and found it was impossible to mount the 8GB drive using USB with SYS 1.64. Trying to load SYS 1.62 with Windows 8.1 always resulted in problems. The good news is loading SYS 1.62 using Windows 7 results in a mountable 8MB drive that can then be formatted successfully. It is then possible to load wildcat 4.3 with everything working properly. The test files would not load and run with Windows 7 including the reduced ROM and RAM version which did load but did not run. The reason I was using SYS 1.64 was 1.62 loaded by Windows 8.1 crashed with a hole in the splash screen every time. Loaded by Windows 7 it was fine. I tried multiple computers to see if the Windows 8 issues were related to the particular box but they all failed to load DFU files the same way. I tried running Windows 7 as a virtual machine via Parallels on a MacBook Pro and that also worked well. Loading wildcat 4.4 onto the working setup running 4.3 on SYS 1.62 trashes it with either Windows 7 or 8.1 (hardware 2.81). Thanks again for your help.