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

I'm using the Segger nRF52840-DK and I want to add support for SPI?

I'm using the nRF52840-DK evaluation software from Segger. I want to add NAND Flash support, so I want to add an SPI interface. I have looked at the example in nRF5SDK160098a08e2 and that works nicely on my board, but I'm having difficulty moving that SPI example to the nRF52840-DK project as there are dependencies on Integration, module and components folders. isn't there a much simpler way to just add SPI support like there is when using ST Micro Cube IDE? I did manage to have a successful build with nrfx version of SPI, but the driver won't work correctly on my board.

I'm using the latest version of Segger Embedded Studio.

Regards,

John

Parents
  • Hello again John,

    Attached to this message you will find a modified version of the fatfs example that uses SPIM instead of the legacy nrf_drv_spi driver.
    The modifications are made to the app_sdcard library, which implements the SPI SD card interface. The modified app_sdcard.c file is located next to the main.c of the project.

    The SD card instance is set to use SPIM3 in particular, which allows for 16 MHz SPI frequency(instead of the 8 MHz maximum of the other channels).
    If you are not using the nRF52840 SoC you will have to change the APP_SDCARD_SPI_INSTANCE in sdk_config to a SPIM instance between 0 - 2, as it is only the nRF52840 that has the SPIM3 instance.

    The example will in other ways behave as described in the fatfs example documentation.
    I tested it with an SD card here on my end and everything worked as expected.

    I hope this will satisfy your requirements for testing the SPIM module for use with the fatfs library.

    Please do not hesitate to let me know if you should encounter any more issues or questions!

    Best regards,
    Karl

    p1.15 SDC_SCK
    p1.13 SCD_MOSI
    p1.14 SDC_MISO
    p1.12 SDC_CS
    fatfs_nrfx_spim3.zip

  • Hi Karl,

    Thank you for all your help. The only problem I have is I still have to use Segger's emFile because I still need their NAND universal driver to talk to the Kiokia TH58CBG2S0HRAIJ part. I'll see if there is some of your code that I can adapt to make my Segger example work.

    Thank you again.

    Regards,

    John

  • Hello John,

    john3909 said:
    Thank you for all your help.

    No problem at all, I am happy to help!

    john3909 said:
    The only problem I have is I still have to use Segger's emFile because I still need their NAND universal driver to talk to the Kiokia TH58CBG2S0HRAIJ part.

    I tried to look up the part you mention, but I was unable to find one matching that exact part number.
    The SDK fatfs driver documentation can be found in the SDK, located at: PATH/SDK/external/fatfs/doc/00index_e.html

    Were you able to run the example I provided without issue, by the way?
    - Is there any fatfs functionality you are missing with the fatfs driver provided in the SDK?

    Best regards,
    Karl

  • Hi Karl,

    The part is compatible with any Kioxia (previously Toshiba) SPI part:

    https://www.digikey.com/products/en/integrated-circuits-ics/memory/774?k=nand+flash&k=&pkeyword=nand+flash&sv=0&pv142=227634&sf=0&FV=-8%7C774%2C-1%7C1853&quantity=&ColumnSort=0&page=1&pageSize=500

    For Segger emFile, I only had to write the SPI access layer (init, read byte, write byte, lock, unlock, etc). Their universal driver would read the part ID and then use the appropriate command structure to access the part. For your part, I would have to write the sector/block code and deal with ECC, etc. Am I correct? Do you have an example driver I can use for reference.

    Regards,

    John

  • Oh, and one more thing, we are also looking at using eMMC with SDIO 4 or 8Bit mode to minimize the time to write. This is a requirement because we would like to run on a CR2032 battery for 8 hours.

    Regards,

    John

  • Hello again John,

    john3909 said:
    Oh, and one more thing, we are also looking at using eMMC with SDIO 4 or 8Bit mode to minimize the time to write.

    The modern eMMC standard does not support SPI, and the nRF52840 does not support eMMC so to achieve this you would need an additional eMMC controller IC. For more detail please see this ticket.

    john3909 said:
    This is a requirement because we would like to run on a CR2032 battery for 8 hours.

    What other peripheral do your application use, and how often is it in use?
    I do not know anything about your application or its use-case, but 8 hours is a very short lifespan of a device in the field. Is it perhaps meant to be deployed as a temporary sensor unit of some sorts?
    I would think 8 hours as a target is achievable - but then again I do not know much about what you plan on having the device do.
    If you could elaborate more on that, I could advice you on power optimization.

    john3909 said:
    For Segger emFile, I only had to write the SPI access layer (init, read byte, write byte, lock, unlock, etc). Their universal driver would read the part ID and then use the appropriate command structure to access the part. For your part, I would have to write the sector/block code and deal with ECC, etc. Am I correct? Do you have an example driver I can use for reference.

    No, if I understand what you are asking me correctly, this is handled by the fatfs driver - ie. you may use all the functions listed in the /external/fatfs/doc/00index_e.html documentation directly, once you have fatfs disk is initialized. The initialization abstracts the memory to a block device, which is an universal abstraction for block based memory - from there on out all fatfs volumes are accessed the same.

    Best regards,
    Karl

  • Hi Karl,

    The device has several sensors that are sampled every 2mS and stored to a 128K buffer and then stored to SDCard when the buffer is full. The SDCard is the only device that consumes a lot of power (100mA during read/write), so we have this powered down for most of the time and only power up when writing. We want to keep the write as short as possible, so a 4bit operation is preferred.

    Do you have an NAND Flash example driver we can used as a reference. The link you provided refers to another document that is referencing the same part as ours, but on the BMD340 part.

    Thank you for all your help,

    Regards,

    John

Reply
  • Hi Karl,

    The device has several sensors that are sampled every 2mS and stored to a 128K buffer and then stored to SDCard when the buffer is full. The SDCard is the only device that consumes a lot of power (100mA during read/write), so we have this powered down for most of the time and only power up when writing. We want to keep the write as short as possible, so a 4bit operation is preferred.

    Do you have an NAND Flash example driver we can used as a reference. The link you provided refers to another document that is referencing the same part as ours, but on the BMD340 part.

    Thank you for all your help,

    Regards,

    John

Children
  • Hello John,

    john3909 said:
    The device has several sensors that are sampled every 2mS and stored to a 128K buffer and then stored to SDCard when the buffer is full. The SDCard is the only device that consumes a lot of power (100mA during read/write), so we have this powered down for most of the time and only power up when writing. We want to keep the write as short as possible, so a 4bit operation is preferred.

    I understand. Reducing the active SDCard time will definitely help your power consumption.
    Perhaps you would want to use the SPIM3 from the example at 32 MHz instead of the 16 MHz it is currently configured to?
    Be advised that you then might have to increase the drive strength of the SCK and MOSI pins, depending on your hardware configuration - given that your SDCard supports this frequency, that is.

    john3909 said:
    The link you provided refers to another document that is referencing the same part as ours, but on the BMD340 part.

    Yes, the other user seem to be using the same NAND Flash - interfaced using SPI. However, I do not know if that user had the same power constraints as those present in your project.

    john3909 said:
    Do you have an NAND Flash example driver we can used as a reference.

    The fatfs_spim example was intended as such. Could you elaborate more on what specific functionality you would like to see demonstrated?

    Best regards,
    Karl 

Related