The problem is simple. I have a binary file main.bin (696 bytes) and I want to program it into flash.
I program it with SAM-BA, it works. I read it in openocd with “mdb 0x00100000 696” and it is same like the binary main.bin.
I program it with openocd, with “flash write 0 main.bin 0x0”, it doesnt work. When I read it with openocd "mdb 0x00100000 696, I get the same binary like main.bin on my HDD between 0 and 618 byte (its ok), then 619 byte is 0x00 (wrong) and 620-696 bytes are FF (wrong).
My hardware is at91sam7x256 programmed with jtagkey clone, my openocd is the openocd-2006re76-setup-rc01.exe. My system is WindowsXP (cygwin, gnuarm, etc.)
My config and instructions scripts are based on Martin Thomas flash programming tutorial which I found on his page.
Well… I downloaded the source from SVN, then compiled it under cygwin, changed the old binary openocd.exe to new… and it works now :>.
To be sure, I tried again to write flash with old openocd.exe and then again with new compiled version. Now I’m sure (I think so that this problem is solved in most uptodate version from SVN.
I also tried NVM bit patch for openOCD and it works fine too.
glad you got it working. I believe there’s a “bug” in the OpenOCD when it’s compiled for MinGW (Michael uses MinGW for his releases), while it works fine on POSIX compliant systems (including Cygwin).
In my happy happy POSIX world, binary and text files are treated equally - MinGW and the native WIN32 API on the other hand treat them differently. The OpenOCD opens binary files with a simple fopen(…, “r”), which is fine for POSIX, but fails on Windows. When fread encounters a 0x1a (^Z) for example, it signals EOF, and returns only the number of characters read until then (though I believe the whole request is executed anyway, i.e. all bytes have been read).
Anyway, I’m almost done with integrating the MinGW stuff, and you shouldn’t encounter these problems again.
Now I dont have access to my files because I’m at home (and my ARM is at work), but as far as I remember, a first char which had been broken after uploading to flash was 0x1A just like you said :>. So now we have the problem clear ;).
Now I’m going for 2 week holidays and after that, I’ll try to run the whole enviroment including GNUarm + OpenOCD + Eclipse ;).
that this problem is solved in most uptodate version from SVN.