xiaotailang opened a new issue, #10236: URL: https://github.com/apache/nuttx/issues/10236
Hello everyone! I have developed an SPI flash W25Q16 driver on STM32F767. The upper-level interface is managed by the MTD device, with the W25Q16 device mounted on the /mnt/ directory. I transfer the file "1.txt" through FTP or socket, and then open the W25Q16 device using the open function. After that, I write "1.txt" to the W25Q16 using the write function. In general, the write operation works fine,However, I have found that after a power loss and system reboot, when I transfer "1.txt" through FTP or socket and then write it to the W25Q16, the file is often not visible when using the ls command to check the contents of the W25Q16. This issue is more likely to occur if "1.txt" already existed in the W25Q16 flash before the power loss, and I attempt to write it again after reboot. I have confirmed that the file was accurately transmitted through FTP or socket..I have tried debugging and tracing this issue, but I haven't been able to pinpoint the specific problem. Since you have ex tensive development experience, can you provide some solutions or suggestions for troubleshooting? The specific phenomenon： +++++create socket sucess ++++ +++++ connect sucess ++++ +++++++++++++nxffs_open++++++++++++++++++ nxffs_open_oflags:38 +++++++maybe into nxffs_wropen++++ pos123_oflags:38 pos12_oflags:38 nxffs_findinode_ret:0 pos3_oflags:38 pos1234_oflags:38 pos12345_oflags:38 spi_send:43 spi_send:43 +++++open /mnt/w25a/ sucess ++++ ++++++++++++++++++start wrtie+++++++++++++++++++++++++++ spi_send:43 spi_send:43 spi_send:43 ofile->crefs:1 ofile->oflags:38 spi_send:43 spi_send:43 spi_send:43 wrfile->truncate:1 start---nxffs_rminode spi_send:43 spi_send:43 spi_send:43 spi_send:43 spi_send:43 spi_send:43 receive file name: 1.txt receive file size 5 From the printed information flow above, it can be seen that the file has been successfully transferred and written. However, when I navigate to the "/mnt/w25a/" directory using the "cd" command and check with "ls", I find that "1.txt" does not exist. I have tried writing "1.txt" to an SD card via the SPI interface, and I did not encounter this issue. Upon examining the system, I found that reading and writing to the SPI flash and SPI SD card are implemented using different interfaces. Therefore, I can only confirm that there is likely no problem with the SPI bus driver. However, I cannot completely rule out the possibility of hidden flaws in the interface responsible for managing the SPI flash within the system. As you have a wealth of development experience, I hope get some insights or suggestions. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
