sending Data from CC2340R5 to NTM88 using SPI.

[ankit2631]

I am using NTM88 for BLE based TPMS application, where i am using CC2340R5 for data transmission on BLE. I am able to read the sensor data from NTM88 using SPI but i am not able to write the data in NTM88. i want to send some values in order to set the threshold for pressure and temperature values. but whenever i try to debug the issue by putting it into debug mode the connection gets terminated from NTM88 side. i am reading the sensor data from 0xcf location and trying to write the threshold value to 0x0091 location. i have followed NTM88_GenFSK_Beacons examples.

/*****************NTM88 side************************/

#define ADDR_FIRST_DATA_WRITE_BYTE 0xCF
#define ADDR_FIRST_DATA_READ_BYTE 0x0091

#define NB_DATA_BYTES
#define NB_READ_BYTES 8

#pragma DATA_SEG __SHORT_SEG MY_ZEROPAGE
UINT8 gau8DataArray[NB_DATA_BYTES] @ADDR_FIRST_DATA_WRITE_BYTE;

#pragma DATA_SEG __SHORT_SEG MY_ZEROPAGE
UINT8 gau8ReadDataArray[NB_READ_BYTES] @ADDR_FIRST_DATA_READ_BYTE;

/**************************CC2340R5**************************************************/

static uint8_t u8SpiFillTxBuffer (void)
{
uint8_t i, buffer_index;
uint16_t u16address;

// We fill the buffer from the beginning
buffer_index = 0;

  //READ commands to get the sensor data 

u16address = ADDR_FIRST_DATA_BYTE;
for (i=0; i<NB_DATA_BYTES; i++)
{
vfnSpiFillBufferRead(u16address++, &buffer_index);
}
//WRITE commands to configure TPMS

vfnSpiFillBufferWrite(ADDR_FIRST_WRITE_BYTE, &buffer_index);
vfnSpiFillBufferWrite(0x09, &buffer_index);

// WRITE commands to let the NTM88 resume operations 

vfnSpiFillBufferWrite(ADDR_SPIOPS, &buffer_index);
vfnSpiFillBufferWrite(0x00, &buffer_index);

// Note that it would be necessary to perform an additional transfer to read the WRITE command status

return buffer_index;
}

static void vfnSpiTriggerXfers (SPI_Handle controllerSpi, uint8_t u8nb_bytes)
{
SPI_Transaction transaction;
static bool transferOK = 0;

/* Initialize controller SPI transaction structure */

memset((void *)controllerRxBuffer, 0, BUFFER_LENGTH);

transaction.count = (10);
transaction.txBuf = (void *)controllerTxBuffer;
transaction.rxBuf = (void *)controllerRxBuffer;

/* Perform SPI transfer */
transferOK = SPI_transfer(controllerSpi, &transaction);

return;
}

[TomasVaverka]

Hi Ankit,

Please accept our apologies for the delay in answering your question. I am back at work after the Christmas break and have forwarded your question to our TMPS SW engineer. I will update this thread as soon as I have her feedback.

BRs, Tomas

[TomasVaverka]

Hi Ankit,

Please see below the complete answer from our TPMS SW engineer.

In the function below I see that transaction.count is set to value 10. I am not familiar with these drivers, but I would assume that this represents the number of 16-bit transfers to perform.

If so, there are 12 transfers (not 10) to perform according to the function below.
A READ command is sent via one transfer, and a WRITE command via two transfers. In below function, there are 8 READ commands and two WRITE commands, which makes a total of 8 + 2*2 = 12 transfers.

=> So I would try setting transaction.count to value 12.

And after that, I would recommend monitoring the SPI transactions with a logic analyzer to check the number of content of the SPI transfers. This is good practice to ensure the communication is performing as expected, and to debug communication issues. See below an example of logic analyzer screenshot taken from the application note AN14182, Implementing Wired Communication with the NTM88, showing the detail of the SPI transfers. See section 2 of the app note for detailed information on the hardware SPI block of the NTM88.

The SPI commands and responses are decoded using the SPI encoding and decoding excel file provided with the application note.

We hope this helps.

BRs, Tomas

[ankit2631]

Hello Tomas,

transaction.count=10 in the code below is number of 16-bit transfers, and i am reading 6 bytes and writing 2 bytes so 6+2*2=10. NB_DATA_BYTES is the no. of bytes that BLE IC will read and i have set it to 6. So by the above logic 10 counts is correct number of 16-bit transfers. i have a doubt about the write address location on which BLE IC is trying to write using SPI write operation i.e. 0x0091, is this location correct or am i using incorrect location or sequence?

[TomasVaverka · Accepted solution]

Hello Ankit,

In any project, the address allocated to each object (including variables) can be seen in the map file generated during build and located in the FLASH folder of the project.

The map file has a section named “Object list sorted by address”, which lists all objects sorted by increasing address:

So I would recommend to open that map file, and look which variable is allocated at address 0x91.

0x91 is a valid RAM address, part of the RAM section which is not maintained in STOP1. The map file will allow to check which variable is stored at this address.

Regarding the SPI sequence, we recommend using a logic analyzer to check the entire SPI sequence. If the sequence is as expected, then it means the issue is not with the SPI.

BRs, Tomas

[ankit2631]

whenever i try to debug this issue the connection is terminated by NTM88 as watchdog timeout occurs in the below SPI function.

void vfnTriggerDataTransfer (void)

{

/* Take sensor measurements first, while the MKW is still in sleep to save power */

vfnStoreSensorData();

/* Enable SPI */

SIMOPT1_SPIEN  = 1;

/* It is time for the MKW to read the data => wake up the MKW */

WAKEUP_PIN_HIGH;

/* Wait for the MKW to indicate it is ready to start the transfers 

* We wait in STOP4 to save power. We have already enabled STOP4 for

* the sensor measurements */

if (0 == u8WaitForMkwAck(STOP4_MODE))

{

/* Acknowledge by lowering the pin */

WAKEUP_PIN_LOW;

/* Halt the CPU to prevent memory contention issues during SPI transfers.

* The CPU will resume when MKW clears the bit or on watchdog timeout.

* When watchdog timeout occurs, the program restarts from the beginning

* of the main */

SPIOPS_CORE_TR_HOLD = 1;

}

else // MKW has not acknowledged => transfers are cancelled

{

/* Lower the pin before going back to sleep */

WAKEUP_PIN_LOW; 

}

/* Disable SPI */

SIMOPT1_SPIEN = 0;

return;

}

so i doubt that this issue is occurring due to write operation. the write operation from CC2340R5 side is not able to perform the write operation properly. so can anyone please help me to resolve this issue.