Matthew Dharm wrote: > > If I reset and remount, I get the bad contents. Now it's 1024 > > 0xff (erased flash) instead of 0x00. > > This is likely an incompatibility between the linux vfat and the > device firmware. Right. > The "filesystem" is likely a ram-cache of the firmware. BUT, it > probably doesn't copy the cache back to the flash until after you > reset the device. I have to say that I think the reprogramming happens at erase/copy rather than on reset. > When you reset, the firmware walks through the filesystem, reads the > file, and tries to copy it to flash. Yes, there is programming > firmware in this mode; it is likely burned into the device at the > factory. There is a fair amount of ROM in this chip, including this bootloader as well as a few other stuff. Here's an excerpt from the user manual. --8<-- 19.9 USB communication protocol The LPC134x is enumerated as a Mass Storage Class (MSC) device to a PC or another embedded system. In order to connect via the USB interface, the LPC134x must use the external crystal at a frequency of 12 MHz. The MSC device presents an easy integration with the PC's Windows operating system. The LPC134x flash memory space is represented as a drive in the host file system. The entire available user flash is mapped to a file of the size of the LPC134x flash in the host's folder with the default name `firmware.bin`. The `firmware.bin` file can be deleted and a new file can be copied into the directory, thereby updating the user code in flash. Note that the filename of the new flash image file is not important. After a reset or a power cycle, the new file is visible in the host's file system under it's default name `firmware.bin`. Remark: USB ISP commands are supported for Windows operating system only. Remark: The only Windows commands supported for the LPC134x flash image folder are copy and delete. -->8-- They point out that it's Windows only in another few places too. I'm really surprised to read that in microcontroller documentation, but whatever. Of course it could be made to work one way or another in Linux too. > Thus, without the reset, you can see the ram-cache perfectly. I think the state machine to implement the scheme you describe would be fairly complex. I suspect that they wanted to keep it as simple as possible and that the RAM cache is seeded from flash only on ISP mode entry and not re-seeded if/when the flash is written. Oh well, I'm speculating. Going back to debug mode, am about to try Alan's suggestions now. > The programming code is mis-interpreting what linux puts into the > filesystem. Yes, I think so too. > What that incompatibility is I don't know; I'm hoping we can nail it down, worst case by comparing URBs with what Windows does. > however, I have seen many many bad vfat implementations with all > sorts of goofy behavior. Oh yes. And certainly when it's in a ROM in something like this, where even the documentation has "Windows only" literally written all over it. > > (Is it OK to send the 115kb log to the list?) > > No. Thanks! I guessed as much so put them on the web server. //Peter
Attachment:
pgpupUkrQv5eq.pgp
Description: PGP signature
