nRF52840 FATFS file corruption

Question

I am using the nRF52840 (with SDKv17.0.2 + s140_7.2.0) and made a custom FW based on the ble_app_hrs example. My custom HW has a 128MB MX66U1G45G flash memory chip. 
 The system can stream notification data indefinitely without any issue. The notification packets are 242B long (max MTU is 245B) and the data is sequential 3B integer values starting at the 3rd byte. The first two bytes are a packet counter (0-255) and a packet ID (used by SW). Thus the first packet would be [00 0b 00 00 00 00 00 01 00 00 02 00 00 03 00 00 04 00 00 05 … 00 00 4f] and the second packet would be [01 0b 00 00 50 00 00 51 00 00 52 00 00 53 00 00 54 00 00 55 … 00 00 9f]. The data rate is ~60kBps (100 3B integers are queued every 5ms using a timer), and these are streamed over BLE as soon as 242B (80 3B integers plus two opcode bytes) are ready. 
 I am also trying to store these 242B packets to flash memory as a file via FATFS so that it can be downloaded by Windows via USB MSC. As the 242B are generated and queued for BLE transmission, they are also stored in a ping-pong type buffer. When 4096B of data is accumulated, f_write() is called. The process continues until a stop command is issued or the flash memory becomes full. When this flash logging is enabled, USB MSC is disabled, and when flash logging stops, the system becomes a USB MSC device. 
 This works sometimes, but unfortunately, I am not getting a way to get good (or bad) files reliably/repeatedly and thus am unable to describe the symptoms clearly. For example, in one scenario, I quick format (either by Windows or f_mkfs().Then I create and write to file0. After closing and checking the contents of file0, some of the integers may be repeated, thus causing error. Then I create and write to file1 without a format. Closing and checking the contents of file1 shows that it is okay. Then if I recreate file0, it checks out as fine, but rechecking file1 shows that it had been touched and some of the integers are again repeated, even though I had done nothing with this file. The I go back and recreate file1, and it checks out as good, whereas file0 has now become bad again. After repeating this for a while, Windows might eventually pop up a message saying that the drive needs to be scanned and repaired. 
 Another scenario is this: after formatting, I create and check a single file and it shows the errors. Then I recreate and check the file and it's okay. But this is seemingly random, as multiple runs can give a good/bad file. If I let the flash memory get full (the FW closes the file on full), then Windows says that the disc is bad and unrepairable. I then recreate the file and check it multiple times and it shows the file is good or bad on different runs (after the first re-creation, Windows has to scan/repair the drive). 
 Slowing down the data rate does not help. Any ideas on the issue or advise on debugging this would be greatly appreciated!

Jared · Accepted Answer

Hi,

So I should have been more precise in my last reply. I haven't seen cases with SDK v17.0.2 with this bug, but I assume that it was also affected as the patch was implemented in SDK v17.1.0.

The patch is a bit different from what was suggested in that thread, but should result in the same, namely fix the issue where the file system fails to initialize. The fix was implemented in app_usbd_msc.c:

        case APP_USBD_EVT_STOPPED:
        {
            /*Un-initialize all block devices*/
            ASSERT(p_msc->specific.inst.block_devs_count <= 16);
            size_t i;

            for (i = 0; i < p_msc->specific.inst.block_devs_count; ++i)
            {
                nrf_block_dev_t const * p_blk_dev = p_msc->specific.inst.pp_block_devs[i];
                ret = nrf_blk_dev_uninit(p_blk_dev);
                uint32_t timeout_ms = 250;
                while (ret == NRF_ERROR_BUSY && timeout_ms--)
                {
                    nrf_delay_ms(1);
                    ret = nrf_blk_dev_uninit(p_blk_dev);
                }

                if (ret == NRF_SUCCESS)
                {
                    p_msc_ctx->blk_dev_init_mask &= ~(1u << i);
                }
            }

            break;
        }

I would thus recommend to update to SDK v17.1.0

regards

Jared

nRF52840 FATFS file corruption

Top Replies