Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Using Cypress S25FS512S as QSPI block device

I am using the nRF52840 (with SDKv17.0.0 + s140_7.0.1) and made a custom FW based on the ble_app_hrs example. My custom HW has a 64MB S25FS512S flash memory chip.

I found this ticket which use either 32MB or 128MB (256MB?) flash memory as QSPI block devices. Those memories have 64KB erase sector sizes. Unfortunately, the S25FS512S has either "hybrid" 4KB + 256KB erase sectors (where the first 32KB are 4KB erase sectors) or full 256KB erase sectors. The nrf_block_dev_qspi driver allocates memory of this erase size and 256KB simply would take all available RAM and thus doesn't build. Do I need to change my BOM to a flash memory that supports 4KB or 64KB erase sectors? The MX66U1G45G or MX66U2G45G seem preferable as they have 2x/4x the memory of the S25FS512S and they support 4KB/32KB/64KB erase sizes for the entire flash memory, so kindly confirm no issue with these devices.

Alternately, is there a work-around to make the S25FS512S work? My use case is actually much simpler than could be achieved with a full FATFS implementation. My application is: 1. user enables flash logging to store sensor data to memory. 2. Application FW fully erases flash memory 3. User enables sensors and as sensor data is streamed, it is saved to flash memory on contiguous pages (which speeds the erase process as only sectors whose first page has data need to be erased and I'm not concerned about wear-leveling at this time). 4 User disables logging and the application saves some meta data such as file size to the flash memory 4. User connects to the PC and PC downloads the file over USB MSC. The PC is read only. 5. The cycle repeats if the user wants a new data set. Any advice implementing this on my current HW would be appreciated. Thanks!

Related