spi read with ppi fails when manual read/writes are executed

[madblue]

Hi,

I am using ppi to read some continuous data from a sensor through SPI and i got it working, it reads data in evry 8ms from the sensor through ppi.

but it fails when i am trying to read some data using normal spi read (nrf_drv_spi_transfer()) functions. Is there any restrictions on using these api  while the ppi is enabled?

I have to read some configuration registers based on an interrupt and enable some other functionality. In this case,it either fails on the ppi read data or the manual read writes.

what am i missing ?

I am using a custom board based on nrf52840

sdk 14.00

[Einar Thorsrud]

Hi,

There is no specific incompatibility between the SPI driver and PPI, but it depends on what you do. If you do something outside the driver that makes the state of the SPI(M) peripheral different then what the drivers expects, it will cause problems.

(As a side note, I want to mention that the first SDK release that is suitable for production with the nRF52840 is SDK 15.0.0. So if you plan to use this for a mass produced product you should migrate to a newer SDK version).

[madblue]

Hi Einar,

Thank you for the quick reply.

I am only doing some sensor reg read/write using the spi apis, nrf_drv_spi_transfer. my worry is that, what happens when if i call the manual write when a ppi read is ongoing ? i haven't went through all the documentation on ppi.

What about the priorities, does the ppi read has higher priority over the manual read writes ?

I have noted that  flags used for spi initialization also not working,

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    spi_config.miso_pin = SPI_MISO;
    spi_config.mosi_pin = SPI_MOSI;
    spi_config.sck_pin  = SPI_SCK;
    spi_config.mode = NRF_DRV_SPI_MODE_0;
    spi_config.frequency = NRF_DRV_SPI_FREQ_8M;

    APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL));
    
    nrf_drv_spi_xfer_desc_t xfer = NRF_DRV_SPI_XFER_TRX(&ppi_txbuff_max30003, 1, ppi_rxbuff_max30003, 4); 
    uint32_t flags = NRF_DRV_SPI_FLAG_HOLD_XFER | 
                   NRF_DRV_SPI_FLAG_REPEATED_XFER | 
                   NRF_DRV_SPI_FLAG_RX_POSTINC  | 
                   NRF_DRV_SPI_FLAG_NO_XFER_EVT_HANDLER;  
    uint32_t err_code = nrf_drv_spi_xfer(&spi, &xfer, flags); 
    APP_ERROR_CHECK(err_code);  
  
    spi_start_task_addr = nrf_drv_spi_start_task_get(&spi); 
    spi_end_evt_addr = nrf_drv_spi_end_event_get(&spi);

Even if disable the event handler, it is getting updated.

Do you think the sdk version could cause any problem? i am planning to upgrade but not now as the migration process looks a bit tedious and time consuming. 

[Einar Thorsrud]

Hi,

madblue said:

What about the priorities, does the ppi read has higher priority over the manual read writes ?

There is no priority concept with PPI. PPI simply allows you to trigger tasks in a peripheral using HW signals. So it happens when it happens, regardless of anything else. It is your responsibility to ensure that there cannot be any conflict by ensuring that you finish one operation before triggering the next (being from SW or PPI).

madblue said:

I have noted that  flags used for spi initialization also not working,

Can you elaborate?

madblue said:

Do you think the sdk version could cause any problem? i am planning to upgrade but not now as the migration process looks a bit tedious and time consuming. 

I have not seen enough of your code, but this looks more like wrong usage based on your description. That said, the SoftDevice that is part of SDK 14.x.x is not qualified for nRF52840 so if you are making a BLE product you should definitely migrate. I would advice to do so in any case, though.

[madblue]

Hi,

I have made a test code with sdk17 with only timer and spi and it doesn't have the issue. it doesn't fail as it happened with my older code. 

THanks for the support, i will upgrade my code with latest version of the sdk.

What do you think about the nrf connect sdk ? How good is it compared to the nrf52 default sdk ?

I am in a dilemma on which one to choose for the final firmware.

my application needs 2 spi peripherals, 1 TWI, 2 timers and BLE with extended mtu size >150 and good power consumption  features.  

[Einar Thorsrud]

Hi,

Good to hear.

The choice between the nRF5 SDK and nRF Connect SDK depends on several factors. First of all, check which of the two meets your requirements. If both, then consider if you do not need new features going forward and need a mature SDK, then the nRF5 SDK could be a good choice. If you may need new features going forward or have other preferences for the nRF Connect SDK, then that is probably it.

[madblue]

Thank you Einar.