Not able to get correct sensor data from NTM88?

[Markel]

Hi,

I am using the "GenFSK_Beacons_Demo_NTM88_KW38" example program as reference. The KW38, I replaced with TI CC2640R2F BLE MCU. Here is my connection diagram.

I have ported the KW38 SPI code to CC2640R2F. My SPI transmit buffer gau8TxData[] contents are below. The first byte 0xCF became 0x3F. At NTM88 code there is nothing that decodes this back to 0xCF or is this done internally?

The received 14 byte data I get from NTM88 is wrong.

What I should be receiving from NTM88 is this below.

Regards,

Markel

[Markel]

Hi Tomas,

Ignore my question about the WAKEUP pin. I already fixed that it is just a typo. Anyway, I think we already able to get the NTM88 sensor data to CC2640R2F but at 100000 SPI bit rate speed weirdly slow. At 10Mbits it does not work.

Regards,

Markel

[Markel]

Hi Tomas,

There is no available KW38 Freedom Board to buy. There is no way for me to verify the GenFSK Beacons works.

Regards,

Markel

[Markel]

Hi,

Has the GenFSK_Beacons_Demo_NTM88_KW38 example programs been tested working before? I am not an expert with NTM88 code base, but it functions as slave SPI, but there is no C array to receive SPI data from SPI master. At NTM88 The sensor data is stored at address 0xCF. There is no code that will decode the received data from SPI master and somehow relate it to be reading data at address 0xCF.

At KW38 code SPI is set to 16 bit transfers but the arrays for transmit and receive are size uint8_t for each element. If set to 16 bit transfers then each array element should be size uint16_t.

static uint8_t gau8TxData[NB_16BIT_XFERS * 2] = {0}; //16 * 2 = 32
static uint8_t gau8RxData[NB_16BIT_XFERS * 2] = {0}; //16  *2 = 32

At vfnSpiPerformXfers() at spi_communication.c, u8xfer_nb_bytes returns 32, that means KW38 is supposed to do 32 x 8 bit transfers

void vfnSpiPerformXfers (void)
{
uint8_t u8xfer_nb_bytes;

/* Prepare the Tx buffer for SPI transfers */
u8xfer_nb_bytes = u8SpiFillTxBuffer();
/* Launch the SPI transfers - this is a blocking operation */
vfnSpiTriggerXfers(u8xfer_nb_bytes);

/* Store sensor data in the application buffer.
Note that the returned status is discarded here, but in a final application it should
be used to check the validity of the data received and do a re-try in case transfers
were not successfully */
(void)u8SpiStoreData();
}

Regards,

Markel

[Markel]

Hi,

This is my logic analyzer capture of handshaking and SPI communication between CC2640R2F and NTM88. There are 2 SPI transactions every 2 seconds. Is this correct?

Regards,

Markel

[TomasVaverka]

Hi Markel,

I need to discuss it with our TPMS SW application engineer who is out of the office this week, returning on Monday the 23rd of May.

Best regards,

Tomas

[Markel]

Hi Tomas,

Thanks for the reply. I think the NTM88 hardware SPI is not supported, based from reviewing the NTM88_GenFSK_Beacons, it just saves the sensor data at a C array at RAM address 0xCF. This 0xCF has nothing to do with SPI. There is no mention of 0xCF at NTM88 datasheet.

Also upon reviewing the NTM88 Firmware Library User's Guide, what is supported is a simulated SPI interface using PTA1 as clock and PTA0 as data. I tested this simulated SPI interface and it did not work also. The PTA1 and PTA0 just stays constantly high. I have a post asking about simulated SPI interface.

Regards,

Markel

[TomasVaverka · Accepted solution]

Hi Markel,

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

The three library functions TPMS_MSG_INIT, TPMS_MSG_READ and TPMS_MSG_WRITE are provided to simulate a SPI block by software. They were developed for the previous TPMS generation (FXTH family) which does not include a hardware SPI block. These functions are present in the NTM88 library for backward compatibility, for customers who are using this simulated interface with the FXTH and wish to migrate their application to the NTM88.

The NTM88 includes a hardware SPI slave block, so using the hardware block instead of the simulated interface is generally the preferred solution for customers. All our NTM88 demo projects use the hardware SPI block.

As mentioned before, the NTM88 SPI transfers are 100% handled by hardware and not by the application. As a consequence, there is no reception or transmission buffer to declare in the NTM88 application. In other words, once the SPI is enabled in the NTM88, all transfers are directly handled by the hardware block only, and not by the application.

The host MCU must send SPI commands with the format detailed in the user manual. Custom SPI frame format is not supported.

The SPI commands allow the host MCU to read and write the entire NTM88 memory.

In the demo project, sensor data is stored starting at address 0xCF. Any address in RAM can be used as the host MCU can access the entire memory map of the NTM88. There is no address reserved for the SPI.

The GenFSK Beacons demo is fully functional. A screenshot of the SPI transfers is provided in the user guide, in section II. SPI communication between the NTM88 and MKW. The data read by the host MCU via SPI is then transmitted in a GenFSK Beacons. The Beacon frame can be received with a smartphone and the content displayed on the TPMS BLE app mentioned in the user guide. Screenshots of the app displaying the data received are provided in the user guide.

In your CC2640R2F project, make sure to implement the correct SPI frame format, as indicated in the demo user guide and described in the NTM88 user manual.

Best regards,

Tomas

[Markel]

"The three library functions TPMS_MSG_INIT, TPMS_MSG_READ and TPMS_MSG_WRITE are provided to simulate a SPI block by software. They were developed for the previous TPMS generation (FXTH family) which does not include a hardware SPI block"

There is no note mentioning that these 3 C functions are not applicable for NTM88.

"The GenFSK Beacons demo is fully functional."

I will know for sure after I buy the KW38 so I can test it.

Another issue is that at NTM88_GenFSK_Beacons example program can you confirm if this code for WAKEUP_PIN_HIGH and WAKEUP_PIN_LOW are correct.

/* Wake up pin configuration*/
#define WAKEUP_PIN_HIGH PTBDD_PTBDD0 = 1; PTBD_PTBD0 = 1
#define WAKEUP_PIN_LOW PTBDD_PTBDD0 = 1; PTBD_PTBD0 = 0

I am using the board X-TPMS88EH11S434 and we are using PTB1 for WAKEUP_PIN_HIGH and WAKEUP_PIN_LOW. The original code above works reversed for the board X-TPMS88EH11S434. So, I change it to this below.

#define WAKEUP_PIN_LOW PTBDD_PTBDD1 = 1; PTBDD_PTBDD1 = 1
#define WAKEUP_PIN_HIGH PTBDD_PTBDD1 = 1; PTBDD_PTBDD1 = 0

After that changed I am able to get data at MISO pin. But, I still get the wrong values at CC2640R2F.

Anyway, thanks a lot for the information. I think I will buy the KW38 first and verify the GenFSK Beacons.

Regards,

Markel