[En-Nut-Discussion] UFLASH Write Appends Trash Data

[Bob Wirka]

Ole,
Thank you for your reply.
I have updated my svn version of the trunk from Source Forge.
When you speak of the latest dataflash and uflash implementation, do you mean only "/dev/spi_flash_at45d.c" and "/fs/uflashfs.c"? Or are there other files that I should update?
I see the checksum changes in the spi driver, and the memory leak fix in uflashfs.c. If it's only those two files, that would be great. With other files I see some new #defines that would have to get dragged in.
Hope you're doing well, and thanks again for your help.
Best regards,
Bob
      From: Ole Reinhardt <ole.reinhardt at embedded-it.de>
 To: en-nut-discussion at egnite.de 
 Sent: Saturday, March 21, 2015 9:57 AM
 Subject: Re: [En-Nut-Discussion] UFLASH Write Appends Trash Data
   
Hello Bob,



Am 21.03.2015 15:21, schrieb Bob Wirka:
> Running Ethernut 4.10.3 on an AT91SAM7X512 with UFLASH and an AT45DB161E data flash.
> After each reboot, we refresh a small (8K) xml file by recreating it and writing it to the flash file system.
> Normally this works perfectly. However if we modify another file so that the IP address will change and then reboot, the xml file we create has about 1400 "FF" characters and some "random" bytes appended to the good xml data.
> Here's the weird part: If, after creating the (bad) xml file, we open a dummy file for writing, close it, then erase it, the xml file is good. The name of the dummy file doesn't matter.
> The file we modify to cause this issue is a configuration file. The issue happens we change the IP address that the unit is to use on the next boot-up. Changing other data in the configuration file doesn't **seem** to cause this issue, though we haven't tested all possible changes.
> After a "bad" xml file has been created, we can FTP the file out from the unit, complete with all the extra bad data.
> Files are closed before rebooting.
> Any of this sound famiiar?

Could you please try again with the latest dataflash driver and uflash
implementation in Nut/OS Trunk?

In January I fixed several issues with the dataflash drivers and
uflashfs. The CRC calculation had been broken on at45df dataflashes for
example.

Further please keep in mind that your files may never end by 0xFF bytes,
as this value is used by uflashfs to calculate the free space in a
block. (I consider this a bug by design :)

If you still see issues with latest Nut/OS, could you provide a simple
test case (files and code?)

Best regards,

Ole




-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48        Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion