CC2640R2F: Not seeing any RX data when using SPI_MODE_CALLBACK transfermode.

lakshmikanth satyavolu

Part Number: CC2640R2F

Tool/software:

Hi Community,

I am using SPI0 for my external flash memory in my custom design. It was working perfectly when I use SPI_MODE_BLOCKING as transfer mode. Recently I had to use it in non blocking mode and I changed the transfermode to be SPI_MODE_CALLBACK.

My call back is getting invoked for each transfer and I am seeing that the transaction status is becoming SPI_TRANSFER_COMPLETED. transfer count also matching perfectly. But I am not able to see any receive data inside my rx buffer.

Below are my initialization & read flash ID routines for your reference:

int smartMCT_SPI0Init(void)  // SPI0 init
{
//SPI0 init

    SPI_Params_init(&SbpSpiParams);
    SbpSpiParams.bitRate = 8000000;

    SbpSpiParams.transferMode =SPI_MODE_CALLBACK;
    SbpSpiParams.frameFormat = SPI_POL0_PHA0;
    SbpSpiParams.dataSize = 8;
    SbpSpiParams.transferCallbackFxn = wdt_spi_cb;
    SbpSpiHandle = SPI_open(MY_SPI0, &SbpSpiParams);
    if(SbpSpiHandle == NULL)
    {
        return -1;
    }
}

// Reading flash ID 
uint8 MH_SPIReadID(uint8 addr,uint8 *out)
{

     txbuf[0] = 0x9F; // read command 
     txbuf[1] = 0xFF;
     txbuf[2] = 0xFF;
     txbuf[3] = 0xFF;
     txbuf[4] = 0xFF;
     txbuf[5] = 0xFF;
     txbuf[6] = 0xFF;
     txbuf[7] = 0xFF;

     spiTransaction.arg = NULL;
     spiTransaction.count = 8;
     spiTransaction.txBuf = txbuf;
     spiTransaction.rxBuf = out;

     PIN_setOutputValue(myPins, MH_CS, 0);                              // /CS enable
     SPI_transfer(SbpSpiHandle, &spiTransaction);
     PIN_setOutputValue(myPins, MH_CS, 1);                           // /CS disable

     return 0;

}

What could I be doing wrong? Any considerations for receive data in callback mode?

Best

Lakshmi

over 1 year ago

0 lakshmikanth satyavolu 11 months ago

Expert 1680 points

Hi Community,

Would someone please look into this? It is critical for us to proceed further.

Thanks in advance.

Best

Lakshmi

0 Alex Fager 11 months ago in reply to lakshmikanth satyavolu

TI__Genius 12441 points

Hello lakshmikanth satyavolu

Changed uint8 -> uint8_t (had an error here).

I am lacking a bit of context on some of the code functions, are you able to run a version of your SPI code in an empty project? This is to confirm that no other configurations are causing the issue.

The spislave example uses callback mode SPI, this should be a good resource to use here.

Thanks,
Alex F

0 lakshmikanth satyavolu 11 months ago in reply to Alex Fager

Expert 1680 points

Hi Alex F,

Thanks for the response.

1) I am using simple_peripheral_cc2640r2lp_oad_onchip_app as my reference. I am testing callback mode spi in application (before BLE is initialized). Would this be enough? or should I only use application without OAD and stack? Also, blocking mode working perfectly.

2) Another question is, I would like to use SPI in callback mode (in future) during watchdog reset callback. Since blocking mode is not suggested by the driver documentation, I am opting for callback mode of SPI. Does spi callback function work in watchdog reset call back context if I make an SPI transaction?

Thanks in advance.

Best

Lakshmi

0 Alex Fager 11 months ago in reply to lakshmikanth satyavolu

TI__Genius 12441 points

Hello lakshmikanth satyavolu,

1) If its before the BLE stack, and the SPI pins are free then we should be ok, if we have issues we could try another way.

lakshmikanth satyavolu said:
I am testing callback mode spi in application (before BLE is initialized). Would this be enough?

2) Interesting question, we may be able to get away with a uDMA transaction (this is what SPI uses look at section 12.3.4.2) during watchdog (with a regular interrupt), but a SPI callback is another interrupt so whichever one is configured as a higher priority will go off.

Thanks,
Alex F

0 lakshmikanth satyavolu 11 months ago in reply to Alex Fager

Expert 1680 points

Hi Alex,

Alex Fager said:
1) If its before the BLE stack, and the SPI pins are free then we should be ok, if we have issues we could try another way.

What is the other way do you suggest? I am seeing issues with only callback mode. SPI transactions are perfectly working in blocking mode.

My intention is to save some configuration parameters and dynamic indices of my application into external flash when system hangs due to unknown reasons.

one of the below solutions I am looking for:-

1) Save few application's RAM variables into external flash to retrieve them after wdt reset.

2) If there is a way to retain RAM among wdt resets, that would also be great. I have read about SRAM retention in TRM. Would you please point me to any example in SDK which does the same?

3) I tried using NVS writes. But my application size is getting increased to 4 kilobytes more if I use NVS API, which could not be able to fit into the flash.

Any help is highly appreciated.

Thanks in advance.

Best

Lakshmikanth.

+1 Alex Fager 11 months ago in reply to lakshmikanth satyavolu

TI__Genius 12441 points

Hello lakshmikanth satyavolu,

1) Save few application's RAM variables into external flash to retrieve them after wdt reset:

- SPI or using memset should work here (or osal_snv_wirte), though the callback not working is odd since blocking works, just asking but what is the behavior with a breakpoint set?

2) If there is a way to retain RAM among wdt resets, that would also be great. I have read about SRAM retention in TRM. Would you please point me to any example in SDK which does the same?

-I think we can make use of SNV (simple non-volatile storage) here, use the function osal_snv_write, you can look up some more details/use case in the documentation in the SDK here (BLE5-Stack User's Guide (ti.com)

-Like above lets try SNV instead!

Thanks,
Alex F

0 lakshmikanth satyavolu 11 months ago in reply to Alex Fager

Expert 1680 points

Hi Alex,

Thanks for pointing me to the API. It is working for me.

Best

Lakshmikanth

Bluetooth®︎

Bluetooth forum

CC2640R2F: Not seeing any RX data when using SPI_MODE_CALLBACK transfermode.