USB mass storage data corruption when using flashdisk and jedec, spi-nor flash device with 4096 sector size #57828
Replies: 9 comments 1 reply
-
This is how the new MSC class implementation in next USB device stack works. All you have to do is just to make sure Note that while new MSC class implementation has no restriction on the sector-size, major OSes seem to support only the most common values (512 and 4096 are supported on pretty much every OS). |
Beta Was this translation helpful? Give feedback.
-
|
If I understand you correctly, then the next nrf connect sdk release should no longer have this issue as it should contain this new MSC implementation. That would be great! |
Beta Was this translation helpful? Give feedback.
-
Not really. It only covers the workaround you use with 4096, i.e. the workaround will work with the next USB device stack without having to modify Zephyr code (i.e. can be done solely in application). However, I can reliably reproduce Windows 11 "Windows was unable to complete the format." error with 8 MiB flashdisk using 512 emulated sectors on 4 KiB SPI NOR sectors on both the old and next device stack. The error happens for every "Allocation unit size" except for 4096. The problem is that data written does not match data read back, which confirms your data corruption observation. |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm the issue on nRF52840 DK if I power the board solely from nRF USB. If I connect both nRF USB and JLinkOB USB, then everything works as expected, which suggests the issue might not be in the code itself. Is your device bus-powered or self-powered? |
Beta Was this translation helpful? Give feedback.
-
|
I see. At least I will be able to make it work without zephyr code changes. That is the most important to me. To confirm, I see the problem on the nRF5340DK without or without powering via bus or self powered. And the problem vanishes if 4096 is used without changes power approach. |
Beta Was this translation helpful? Give feedback.
-
|
I cannot reproduce this on nRF5340DK, neither with old nor next device stack. On nRF5340DK everything works as expected if I have only nRF USB connected. How do you determine that there is a problem? Can you share your application and/or do you see the issue with any sample? |
Beta Was this translation helpful? Give feedback.
-
|
I noted your issue with different power scenarios and I just changed the nrf5340dk to run in high power mode (3.3v). Now it is working with either nRF USB alone or with jlink power. Previously it was running at 3v (still well within my spi-nor voltage range). Both default 512 sector size or my hardcoded 4096 it is now working. Also worth noting that I had to give a larger stack size to the msc.c thread with CONFIG_MASS_STORAGE_STACK_SIZE otherwise I was getting stack overflow. (That might be because I am running a slow SPI bus to the nor flash). Since this is working now for the default sector size I guess there isn't a bug. Although I am glad that will be able to set the sector size from the application in the next SDK release. |
Beta Was this translation helpful? Give feedback.
-
|
I measured MX25R6435F Vcc voltage at SB16 on nRF52840DK (PCA10056) during the failing format operation (powered only via nRF USB). The voltage repeatedly does drop below the minimum 1.65V for approximately 100us. There is also some ringing visible. This pretty much convinces me that the issue is not in the software.
|
Beta Was this translation helpful? Give feedback.
-
|
Even though my spi-nor has a max current draw of only 30ma when programming, the nrf5340dk is powering other devices that all together have a fairly significant current draw. So it is entirely possible my configuration was also experiencing a voltage drop out causing the data corruption. I don't have the time to verify with my scope unfortunately, but the fact that upping the voltage appears to have fixed it makes sense. Another annoying issue that made figuring this out harder was that spi comms corruption several times seemed to result in my spi-nor chip becoming write protected randomly and without my knowledge. Write protection caused me a lot of confusion because there appears to be no write verification at any point. So Windows would sometimes appear to format the drive and even allow me to drop a file onto it. But as soon as the disk cache was flushed it would revert to the previous state. I get this from a performance point of view. But I do wonder if a development mode config could enable some write verification as a development time check that corruption is not happening. This would be a quick indication that something is wrong. Once I realised this was happening I added code to SPI-NOR to report to me the write protection status and clear it if not as expected. |
Beta Was this translation helpful? Give feedback.
-
Let's turn this into a discussion. Perhaps some clarification is needed in the board documentation. |
Beta Was this translation helpful? Give feedback.
-
I am using CONFIG_SPI_NOR_SFDP_RUNTIME=y to configure the spi nor flash device which has a sector size of 4096.
I am using this In conjunction with flash disk and usb mass storage to enable support for windows usb mass storage device.
The flash disk ("zephyr,flash-disk") configuration supports sector-size property which if set to some value other than 512 causes zephyr\subsys\usb\device\class\msc.c to throw a runtime error "Block Size reported by the storage side is different from Mass Storage Class page Buffer - Aborting". This is due to msc.c testing the returned sector size from the flash disk with its hardcoded value of 512.
If using a spi nor flash device with a sector size of 4096 then leaving the sector size as the default 512 allows the system to run but causes data corruption when used with windows 11 to format or read/write files to it (not tested on anything else).
Changing #define BLOCK_SIZE 512 to #define BLOCK_SIZE 4096 in the msc.c file
and adding the property sector-size = < 4096 >; to my overlay for the flash disk fixed the problem.
Obviously having to edit the Zephyr code is not an ideal situation. Maybe msc.c should accept the value it gets from the flash disk device for sector size and not impose its hardcoded value.
OS: windows
Toolchain: NRF SDK 2.3.0
Beta Was this translation helpful? Give feedback.
All reactions