Hi Matthew, I very much appreciate the quick and good replies! Matthew Dharm wrote: > In that category of "quick things to try", try mounting with -o sync > and see if that makes a difference. Same problem, both with mount -o sync -t vfat and mount -o sync -t msdos. As expected, the ~one second delay is then on cp instead of umount. > Also, when you say "prepended", do you mean the file is 1024 bytes > larger, exactly, then what you wrote? And that the data read back > is 1024 bytes of 0x00 followed exactly by the exact data pattern > you wrote? The file is always 32kb. A complication is that the filesystem is not really a plain filesystem.. It looks like one, but it's just an "API" to programming the internal flash memory. When mounting the filesystem and reading the file, it always contains the flash memory contents. I'm not sure exactly how flash erase and flash write works internally (what happens when I rm, and what when I cp) - but if mounted async then sync after cp and umount both take a seconds or so to complete. In any case, the User Manual is clear that the flash memory is rewritten by copying a new file to the filesystem. In Windows, the drive can not be ejected, so when the copy command returns on Windows I simply unplug the device, which works. The incorrect data read back is 1kb 0x00 followed by the first 31kb of the 32kb file that I wrote. Same result also if I write a smaller file; I then get 1kb 0x00 + full contents of my file + previous flash memory contents. Always 32kb. > What happens if you mount, write, umount, walk away for 5 min, mount, > readback, and compare -- all without actually detaching the device and > re-booting it I usually reset the device without detaching it. There's a proper reset switch on the microcontroller RESET# signal. I just tried this, and the file read back has correct contents. If I reset and remount, I get the bad contents. Now it's 1024 0xff (erased flash) instead of 0x00. > (which triggers the upgrade process)? I believe that the flash is rewritten when I run cp/umount. After the next reset, the flash needs to already be written. I think that the file contents exposed by the device is cached in the ISP bootloader. It fills the cache with flash contents when starting up, and after that all read operations read from the cache. And writing goes into the flash memory. > > > It would seem very improbable that this was caused by a USB storage > > > issue. > > > > I'm starting at the bottom of the driver stack. :) Maybe you can help > > me debug it in any case? Since this is a very small amount of data, > > might it be informative to add a debug print e.g. for every sector > > write? > > If you turn on CONFIG_USB_STORAGE_DEBUG you will get some pretty > useful but still reasonably high-level data. 1483 lines of debug output is at http://stuge.se/lpc1343_isp.txt (Is it OK to send the 115kb log to the list?) //Peter
Attachment:
pgpqVahonb30z.pgp
Description: PGP signature
