• State Verified Answer
  • Replies 2 replies
  • Subscribers 93 subscribers
  • Views 876 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 293156
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

USBD_MSC example and porting custom FW to PCA10056 issue

Tosa

I am using the nRF52840 DK (PCA10056 2.0.1) with SDK v17.0.2 + s140_7.2.0 and am having trouble with the USBD_MSC example. When plugged into my Win 10 PC, three drives show up. Two are 190KB drives and one is the correct 8MB drive. The 190KB drives cannot be formatted by Windows. The 8MB drive seems to work fine in Windows and FATS via the button presses (to format/create 0KB files/list directory) when disconnected from the PC. The same behavior occurs with SDK v17.1.0 and was tested on two different Win 10 PCs (Lenovo Thinkpad and Microsoft Surface).

In parallel, I made a custom FW based on the ble_app_hrs and usbd_msc examples for my custom HW. My custom HW has a 128MB MX66U1G45G flash memory chip. I’m able to stream BLE data and  format/store/read this flash memory via FATFS and Win 10 without issue. However, when debugging an issue that I was previously having with FATFS causing file corruption (that is now resolved), I tried to port this FW to the PCA10056. nrf_serial_flash_params.c and the pin definitions are the main differences between the two FWs. On the PCA10056, the BLE streaming works fine, but neither FATFS nor Win 10 is able to format the drive (only one 8MB drive shows up versus the three drives in the example as noted above). FATFS returns error code 13 (FR_NO_FILESYSTEM) after formatting and attempting to create a file and Windows pops up a message box saying that it cannot format the drive (similar to trying to format the two 190KB drives in the example). I believe that the pin definitions are correct as the nrf_block_dev_qspi.c:block_dev_qspi_init() shows the correct MX25R6435F ID of 0x c2 28 17 via a NRF_LOG_RAW_INFO statement and runs completely with NRF_SUCCESS. Any idea what is happening? Thanks!

Parents
  • 0

    Hi,

    The 8 MB drive is the external flash. The 190 kB RAM drive should also be formattable from Windows, and is so when I test. However, the empty drive (search for m_block_dev_empty in the main.c of the example) cannot be formatted, and it is not really meaningful. The RAM disk is also of limited value, so unless it is relevant for you I would strip away m_block_dev_ram and related code from the example also, so that you are left with the drive that is on the external QSPI flash.

    Regarding  FR_NO_FILESYSTEM that indicates no FAT filesystem, and you write you get an error when formatting, but I cannot see from here what the issue was.  As I understand you got the 8 MB drive (which is the only flash drive) in the sample working, so it could be interesting to compare your code with the example? And perhaps also your changes to port your app to the DK against the code that is working your your custom board?

Reply
  • 0

    Hi,

    The 8 MB drive is the external flash. The 190 kB RAM drive should also be formattable from Windows, and is so when I test. However, the empty drive (search for m_block_dev_empty in the main.c of the example) cannot be formatted, and it is not really meaningful. The RAM disk is also of limited value, so unless it is relevant for you I would strip away m_block_dev_ram and related code from the example also, so that you are left with the drive that is on the external QSPI flash.

    Regarding  FR_NO_FILESYSTEM that indicates no FAT filesystem, and you write you get an error when formatting, but I cannot see from here what the issue was.  As I understand you got the 8 MB drive (which is the only flash drive) in the sample working, so it could be interesting to compare your code with the example? And perhaps also your changes to port your app to the DK against the code that is working your your custom board?

Children
Related
Terms of service