CC2650: SPI Callback Issues with SLOC297

Team, 

I have a customer working to scan RFID tags with CC2650 and TRF7960A. With the SLOC297 code quasi-working on the CC2650, they can scan a tag but their code gets bricked eventually for an unknown reason and they need a power cycle. Below is a summary of their key code snippets and where they are not clear on how it should be configured.

This is how they open their SPI driver in transferMode=SPI_MODE_BLOCKING. You can see they've commented out the alternative transferMode=SPI_MODE_CALLBACK, which they don't know how to implement. Perhaps after reading notes here the recommendation will be to help them setup SPI_MODE_CALLBACK?

static bool Spi_open(uint32_t bitRate, SPI_FrameFormat frameFormat) //CHANGE was static
{
 /* Configure SPI as master */
 SPI_Params_init(&spiNFCParams);
 spiNFCParams.transferMode = SPI_MODE_BLOCKING;//SPI_MODE_CALLBACK;
 spiNFCParams.transferTimeout = SPI_WAIT_FOREVER;
 spiNFCParams.transferCallbackFxn = NULL;//transferCallback;
 spiNFCParams.mode = SPI_MASTER;
 spiNFCParams.bitRate = bitRate;
 spiNFCParams.dataSize = 8;
 spiNFCParams.frameFormat = frameFormat;

/* Attempt to open SPI. */
 spiNFCHandle = SPI_open(Board_SPI0, &spiNFCParams);

return spiNFCHandle != NULL;
}

Also, they've setup the PIN_Handle and PIN_Config table, and then registered a callback function for the GPIO interrupt when the IRQ line goes high:

static PIN_State pinNFCState;
static PIN_Handle hNFCPin;
static PIN_Config BoardNFCPinTable[] =
{
 Board_NFC_EN | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* NFC initially off */
 Board_SPI_NFC_CS | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MAX,
 Board_NFC_IRQ | PIN_INPUT_EN | PIN_PULLDOWN | PIN_IRQ_POSEDGE | PIN_HYSTERESIS, /* NFC_IRQ is active high */
 Board_LED1 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
 Board_LED2 | PIN_GPIO_OUTPUT_EN | PIN_GPIO_HIGH | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
 PIN_TERMINATE
};

hNFCPin = PIN_open(&pinNFCState, BoardNFCPinTable);
PIN_registerIntCb(hNFCPin, Trf796x_Callback);

In the following implementation of the callback function that doesn't work, they have the Trf796x_Callback ported over from SLOC297 as shown below. In this case they are faced with the challenge of making SPI_MODE_BLOCK calls from a GPIO interrupt callback function which is causing them to get stuck in Hwi.c in an infinite while loop where there is no exception handler. We found some weak online discussion about this not being a good combination (i.e. Blocking function calls inside the GPIO interrupt callback function).

static void Trf796x_Callback(PIN_Handle handle, PIN_Id pinId)
{
 uint8_t ui8IrqStatus;

STOP_COUNTER; // stop timer mode

g_ui8IrqFlag = 0x01;

do
 {
 IRQ_CLR; // PORT2 interrupt flag clear

// IRQ status register has to be read
ui8IrqStatus = TRF79xxA_readIrqStatus();

if(ui8IrqStatus == 0xA0) // TX active and only 3 bytes left in FIFO
 {
 g_sTrfStatus = TX_WAIT;
 break;
 }
 else
 {
 TRF79xxA_processIRQ(&ui8IrqStatus);

}
} while(IRQ_PIN_STATUS);//(IRQ_PORT & IRQ_PIN) == IRQ_PIN);
 //__bic_SR_register_on_exit(LPM0_bits);
}

So the work around was to simplify the Trf796x_Callback function to just set a flag, and then they wrote an application callback function which is polled to see if that flag is set, but they are having issues with that. Ultimately, they would like to know if they should be configuring their SPI Driver to operate as transferMode=SPI_MODE_CALLBACK so that they can leave the Trf796x_Callback as is above and make SPI calls from inside the routine without getting stuck in an Hwi.c infinite while loop.

Any thoughts?