nRF52840 SPIM and Toshiba SPI Nand Flash

RE: nRF52840 SPIM and Toshiba SPI Nand Flash

Einar Thorsrud — Mon, 20 May 2019 07:44:23 GMT

Hi,

[quote user="rodims"]Would it be different if I use the SPI peripheral instead of the SPIM ?[/quote]

The SPI peripheral does not support DMA, do you would have to process every byte in and out continuously in SW. If that is what you want ("looping around a 1 byte transfer") then it might be simpler than using 1 byte transfers with the SPIM peripheral (it should not be a big difference though, as the driver anyway abstracts away any differences).

Generally, SPI is just a standard way of transferring data, and any meaning you put into this data (for instance if it is command, status or just dummy data) is application specific and depend on the chip you communicate with (TC58CVG2S0HRAIG). Therefor you will not find explicit support for any of this in the nRF HW or driver, but you have to implement the protocol for the external flash chip yourself (as you are doing).

RE: nRF52840 SPIM and Toshiba SPI Nand Flash

rodims — Thu, 16 May 2019 20:16:16 GMT

Well, I do not want explicitly control the "SPI clock". I can imagine not to use the drivers support for the chip select

spi_config.ss_pin = NRF_DRV_SPI_PIN_NOT_USED;

and instead set the CS pin manually. Thus I could

a) set Flash CS line active
b) send my command 0x0F, 0xB0,   (using nrf_drv_spi_transfer)
c)  do
       send dummy 0xff to receive one (status) byte  from the Nand Flash (using nrf_drv_spi_transfer)
     while ( status byte == busy)
d) set Flash CS  line inactive

It does not make sense to setup a transfer to receive e.g. 128 status bytes, and afterwards find out, that after e.g. 42 status queries the Nand Flash already was no longer busy. So the question only is, how can I optimize (speed) the looping around a 1 byte transfer. I will try my above idea.

Would it be different if I use the SPI peripheral instead of the SPIM ?

RE: nRF52840 SPIM and Toshiba SPI Nand Flash

Einar Thorsrud — Thu, 16 May 2019 11:34:32 GMT

Hi,

a) The SPIM peripheral does not allow you to control the clock separately. Rather, you have to set up transactions where data (dummy or not) is transferred in and out. That is regardless of whether you control it directly via registers or use the driver. I recommend you use the driver, as that simplifies and makes the code more readable. Moreover, it is properly tested, so you will probably both save time and achieve better quality compared to writing yourself. Regarding the chip select signal you can use a SW controlled GPIO pin that you handle yourself if you need to control it in a flexible way.

b) No, not as far as I can see.