Hi again.
OK thanks to Alampert and others I now understand a little more about the Quad.
Ive now run into another problem though…
I want to put PAWN on slot 4 of my quad and try out Gabonator’s nice looking FW.
I can get into DFU mode and it shows up on my PC (win7) as a 493KB FAT drive.
However, when I try to copy or drop the .HEX file into the drive (DFU_V312 C) it looks like it is copying but doesn’t copy anything and then says the File (i.e. DFU drive) is no longer available…
Anyone have any fixes for this?
Should I format the drive? If I do, will I mess everything up?
OK. Something totally and wholly bizarre…
I read that someone had managed to burn version 8 of QuadPawn to their 8 MB DSO quad without any problems except for the file issues si I tried that.
It worked but of course I couldn’t load any .amx files into the USB that it would recognize.
Then on a whim I renamed the PAWN_011.HEX file to PAWN_008.HEX and it uploaded with no problems.
So now I have QUADPAWN build dated Nov 3 2013 at 16:13:20
Git id version 0.11
GCC version 4.7.4 20130613
running on my DSO quad 8MB AND I’ve got the .amx files in my USB drive AND they work!
So HTF did that happen?
I am now getting something similar to this. DFU3.11C on a 2MB device from Windows 7 64 host.
I was doing a bit of re-organising and find that Pawn_011.hex won’t load and in my case renaming it doesn’t help.
Behaviour is that DFU disk comes up and shows as a 500K drive as normal. When I copy the file, I get the copying dialog which stays up doing nothing then eventually fails saying DFU device doesn’t exist. DFU device is still on Explorer tree but now has properties saying it is 0 bytes capacity. Power cycling the DSO into DFU mode restores the capacity but the process repeats.
If I use Pawn_008.hex version then copying proceeds normally and works fine.
I checked the hex file contents and they both look similar structure address-wise.
It would be nice to check out DFU source to see what could trigger this behaviour but I don’t think that is available, …unless someone knows otherwise.
I’ve been playing around with the Pawn11 hex file, to find out what was triggering the load failure under DFU 3.11C. Behaviour might be different under DFU3.12
The loader was objecting to the split hex records at the end of the file.
:035D400020200020
:015D4300015E
[/code]
So there is a normal 16 byte record followed by a 3 byte record, followed by a 1 byte record all at sequential addresses. For some reason the linking is causing the last 4 bytes to be split into 2 records.
If I combined the last two into a single 4 byte record like
:045D4000202000011E
[/code]
Then it loaded fine.
I tested 1 byte records which worked fine, and also there is another example of a split hex record earlier in the file which doesn’t trigger the problem. So it is some more subtle combination that triggers this behaviour in the loader.
In playing around with the hex I found another couple of things. I tended to get err files when the record length was less than 16 and it looked like maybe a buffer in the DFU is not being initialised properly and the checksum fails. If I preloaded with a hex with 16 00’s or the 16 test bytes then it would pass even if I reduced the number of bytes in the record, but otherwise it would sometimes fail.
The other thing that I guess could be predicted is that it looks like overall blocks of records must be aligned on 2Kbyte boundaries. If not then the hex returns an err file. E.g. after a 04 address record the addresses should be 2K aligned. I think the flash is in 2k pages so the DFU will only deal with complete page updates.
I suspect when the PAWN 11 ‘fails’ to load, it is the last records that are not getting picked up correctly. So most of the code may be OK but I wouldn’t necessarily trust it to be completely right. If you just edit the PAWN hex file by replacing the two lines near the end that start :03 and :01 with the line posted above starting :04 then it should load without error.
