nRF52833 waiting for spi select/deselect to start application

[AndrejP]

Hi,

I am using SDK 17.0.2 for a simple scanner project, where nordic SoC is communicating with main MCU via SPI.
The code starts normally on nRF52832, but on nRF52833, it appears as if it is stuck at start until i make select/deselect on SPI... after initial select/deselect from SPI master, it all works normally....

The code doesn't even enter main loop untill i do first select/deselect.

Has anyone else encountered this issue? 

I use central uart example, which i modified to my needs. For nRF52833 i use pca10100e with s140.

If i run original uart example, the code starts as it should... could it have something to do with SPIS??

I was looking at sdk_config and other stuff if there is anyting that i'm missing, but i can't seem to find the origin of the issue.
Still fairly new to programming and nordic SDK, but everything else i managed to solve...

Thank you for the time and looking forward to suggerstions.

BR,

Andrej

[Jared]

Hi,

Instead of showing the disassembly, could you show where in the source code it's stuck before the CS is asserted by the master. I'm assuming that the nRF acts as a slave and you're using the SPIS peripheral? 

 

nRF52833 i use pca10100e with s140

 The correct development kit for the nRF52833 is PCA10100.

regards

Jared 

[AndrejP]

Hi,

Thank you for fast reply!

Yes you are correct. I use the nRF as a slave.
I have added the spis files required to the project, and will later on clean out the stuff i don't need (uart,...)

Ok, so i went and modified required fields in sdk_config for PCA10100, but still same result.
Was my bad for using wrong PCA, but still doesn't make the difference.

I made spis.c/.h files to keep main clean.

#include "sdk_config.h"
#include "nrf_drv_spis.h"
#include "nrf_gpio.h"
#include "boards.h"
#include "app_error.h"
#include <string.h>

#include "BufferFIFO.h"
#include "lxbt.h"

//*************************************************************************************************
//DEFINES
//*************************************************************************************************

#define SPIS_INSTANCE                     1                             //< SPIS instance index. 

//*************************************************************************************************
//DECLARATIONS
//*************************************************************************************************

static const nrf_drv_spis_t spis = NRF_DRV_SPIS_INSTANCE(SPIS_INSTANCE);//< SPIS instance. 
static volatile bool prSpisXferDone;

//*************************************************************************************************
//PUBLIC FUNCTIONS
//*************************************************************************************************

void SPIS_EventHandler(nrf_drv_spis_event_t event)
{
    if (event.evt_type == NRF_DRV_SPIS_XFER_DONE)
        prSpisXferDone = true;
}

void SPIS_Init(void)
{
    nrf_drv_spis_config_t spis_config = NRF_DRV_SPIS_DEFAULT_CONFIG;
    spis_config.csn_pin               = APP_SPIS_CS_PIN;
    spis_config.miso_pin              = APP_SPIS_MISO_PIN;
    spis_config.mosi_pin              = APP_SPIS_MOSI_PIN;
    spis_config.sck_pin               = APP_SPIS_SCK_PIN;

    APP_ERROR_CHECK(nrf_drv_spis_init(&spis, &spis_config, SPIS_EventHandler));
}


void SPIS_ReadWrite(uint8_t *TxData,uint8_t *RxData)
{
  memset(RxData, 0, SPIS_BUFFER_SIZE);
  prSpisXferDone = false;

  APP_ERROR_CHECK(nrf_drv_spis_buffers_set(&spis, TxData, SPIS_BUFFER_SIZE, RxData, SPIS_BUFFER_SIZE));

  while (!prSpisXferDone)
  {
      __WFE();
  }  
}

It apparently gets stuck in SPIS_ReadWrite(). If i remove while loop which has __WFE(); in it, the code starts.

The function itself is called within following function in lxbt.c:

void LXBT_Task(void)
{
  SPIS_ReadWrite(prSpiTxBuf, prSpiRxBuf);
  prSpisParser(prSpiRxBuf);
}

And that is being called in main.c:

int main(void)
{
  // Enable the constant latency sub power mode to minimize the time it takes
  // for the SPIS peripheral to become active after the CSN line is asserted
  // (when the CPU is in sleep mode).

  NRF_POWER->TASKS_CONSTLAT = 1;

  // Initialize.
  log_init();
  //timer_init();
  LXBT_Init();
  SPIS_Init();
  db_discovery_init();
  power_management_init();
  ble_stack_init();
  scan_init();
           
  // Start execution.
  //NRF_LOG_INFO("BLE scanner example started, will print the number of data read after %d seconds",SCAN_LIST_REFRESH_INTERVAL_MS/1000);
  NRF_LOG_INFO("BLE scanner example started!");
  scan_start();


  while(1)
  {
    LXBT_Task();

    NRF_LOG_FLUSH();
  }

But the int main(void) doesn't even get called with 52833(i used a NRF_LOG_INFO at start of main to check that), while with 52832 this code works without issues...

The nRF ICs are on uBlox NINA modules with open cpu, if that might help perhaps.

Another screenshot of whole enviroment after i run debug:

and when i hit pause:

BR,

Andrej

[Jared]

Hi,

AndrejP said:

But the int main(void) doesn't even get called with 52833(i used a NRF_LOG_INFO at start of main to check that), while with 52832 this code works without issues...

 

AndrejP said:

But i don't see  NRF_LOG_INFO("BLE scanner example started!"), which is in main before LXBT_Task, being put into terminal....

Exactly when the logger module prints the logs depends on if you're using deferred or in-place mode. Most of our examples use the logger mode in deferred mode, which means that the logs are only scheduled in a queue when NRF_LOG_INFO() is called, and actually first printed when NRF_LOG_INFO_FLUSH() is called. This would explain why you don't see the log being printed before it goes into the SPIS loop. It's a bit strange that it works with the nRF52832 and not with the nRF52833.Exactly which module do you use?

It seems that you're using the Softdevice. Can you try to replace your WFE() with idle_state_handle() as in the softdevice examples and call that in teh SPIS loop:

regards

Jared 

[AndrejP]

Hi,

Jared said:

Exactly when the logger module prints the logs depends on if you're using deferred or in-place mode. Most of our examples use the logger mode in deferred mode, which means that the logs are only scheduled in a queue when NRF_LOG_INFO() is called, and actually first printed when NRF_LOG_INFO_FLUSH() is called.

Yes, that would explan it. It could actually explain it all.

I actually made very good progress today.

I'll explain just a little bit about whole hardware implementation:
We have a main unit, which has expansion slots... and in these expansion slots we can put different modules.
One of them is this BT module. We use NINA B111 and NINA B400 now in development phase.

What i figured out today is, that the code was actually working, just apparently not on my test unit....
When i moved the module to another unit, it started working... i did that by coincidence, while solving another issue. So now i am looking at other side of communication, if there is something wrong with initiation from main unit... These are two different Hardware revisions of main unit, so might be some issues here...

Now back to opening issue... i didn't see the logs, because at start, we use SPI to get unit info... and if it fails to do so, there is no more communication. And since that was the case here, it could be possible that it is stuck at __WFE, and with logs waiting for flush... it wouldn't come trough...

52832 on the other hand went trough on my unit, and so it reached log flush... which made me see the debug sentences....

I hope this turns out to be just some timing compensation issue at the end so that it works on all revisions of main unit....

Ok, i hope what i wrote makes sense... More sides to the issue than previously tought :D
For now, it seems more work needs to be done on other MCU (SPI master)...

BR,

Andrej

[Jared]

Hi,

This seems plausible. Keep us updated!

regards

Jared