TCAN4550EVM: SPI integration with CC1352

adding the code we are use to read register 0x0000 by the SPI from TCAN4550

/* Initialize master SPI transaction structure */
masterTxBuffer[0] = 0x41;
masterTxBuffer[1] = 0x00;
masterTxBuffer[2] = 0x00;
masterTxBuffer[3] = 0x02;
memset((void *) masterRxBuffer, 0, SPI_MSG_LENGTH);
transaction.count = 12;
transaction.txBuf = (void *) masterTxBuffer;
transaction.rxBuf = (void *) masterRxBuffer;

/* Toggle user LED, indicating a SPI transfer is in progress */
GPIO_toggle(CONFIG_GPIO_LED_1);

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

thanks!

Meron,

This starter code was developed using the MSP430 family of processors. Was the code modified to initiate the SPI drivers of a CC1352 device? Also, what mode is the device in and how are you verifying this?

Regards,

Hi Eric,

As you can see in the attached picture the nWAKE is low and the INH is high, so from my understanding it means it's on normal/standby mode, is it right?

Regarding the starter code, we would like to start from simple SPI read.

From the starter code, we found same SPI settings marked in yellow, that we didn't find in the CC1352 SPImaster project.

please see below some differences, do you think it should still work without those lines?

SPIParam.selectClockSource=EUSCI_B_SPI_CLOCKSOURCE_SMCLK;

       SPIParam.clockSourceFrequency=8000000;

       SPIParam.desiredSpiClock=2000000;

       SPIParam.msbFirst=EUSCI_B_SPI_MSB_FIRST;

SPIParam.clockPhase=EUSCI_B_SPI_PHASE_DATA_CAPTURED_ONFIRST_CHANGED_ON_NEXT;

       SPIParam.clockPolarity=EUSCI_B_SPI_CLOCKPOLARITY_INACTIVITY_LOW;

       SPIParam.spiMode=EUSCI_B_SPI_4PIN_UCxSTE_ACTIVE_HIGH;

thanks for your help

Meron,

With INH high, this indicates standby or normal mode, both of which have SPI enabled, so that shouldn't be the issue. The sections you have highlighted are configuring the clock frequency, as well as how the data is shifted in and out based on the clock edges. If this isn't present, the SPI could be configured incorrectly based on the SPI clock timing. This would explain why the SPI is reading back all 0s. If none of the data is actually being transmitted correctly to the TCAN4550-Q1, it won't respond with anything.

Is it possible to share SPI oscilloscope waveforms?

Regards,

It seems that in the previous massages the picture are not uploaded/attached, can you see the current attached pictures?

Meron,

Thanks for this, it looks like the chip select and clock timing are correct, though there is a spot near the end of the of clock waveform where the clock skips a period. Any idea why that might be happening?

Also, it looks like the device is reporting back some interrupts with the 0x88 at the beginning of the frame. This is reflecting the values of bits [7:0] in register 0x0820, and 0x88 from those bits is indicating a global error and SPI error. Global error is just indicative of any interrupt or error being asserted, but SPI error is more interesting in this case. And the fact that it's reporting anything back means your SPI configuration is correct, but something is causing the rest of the frame to not report any information back.

Verify that you have the SPI clock and chip select configuration correct based on page 42 of the datasheet, from the screenshot it looks like it is, but I just want to verify. Also, look through the software user's guide in the TCAN4550-Q1 folder, it will give a bit more guidance on the SPI and TCAN4550-Q1 configuration.

Regards,

hi Eric,

can you help us understand this issue? 

maybe it is clock issue? as you wrote before there is a spot near the end of the of clock waveform where the clock skips a period.

the HOST is CC1352(TI) and we are using the SPI master example code, can you please help us here?

thanks,

Meron 

hi Eric,

when I use with SPI lab generator, it works and I succeeded to read registers from the TCAN4550.

but when we use the CC1352 it doesn't works.

in order to compere between the to hosts, we found that the SPI transaction looks diffrent.

the CC1352 toggle the CS every 8 bit and the SPI generator the CS only once for all the transaction, for read 12*8bit.

can you please help us to change the CC1352 CS to behavior like the SPI generator?

attached 2 pictures from Oscilloscope one CC1352 and one of the SPI generator.

thanks,

Meron,

I would expect the chip select burst of 8 bits to still work okay with the TCAN4550-Q1, but there may be some setup and hold time issues. Let us see if changing the chip select to a constant low during the entire transaction will help. Engineers from the team supporting the CC1352 have been notified of this thread.

Regards,

Eric Hackett

Hi Meron, 

Have you confirmed what happens on the CC1352 side? Can you show a complete plot from the SPI generator? 

From what I can see, it seems like you set the tx buffer to 4 bytes, then mention that you want to transmit 12 bytes, but on the oscilloscope there are 8 pulses. Can you please explain what you are trying to do on the CC1352 side, which example you are using and how it is configured? 

Thanks, 
Elin 

hi Elin,

the code we are using are base on SPI master example, with the following SPI settings:

/* Open SPI as master (default) */
SPI_Params_init(&spiParams);
spiParams.frameFormat = SPI_POL0_PHA0;
spiParams.bitRate = 4000000;
spiParams.dataSize = 8;
masterSpi = SPI_open(CONFIG_SPI_MASTER, &spiParams);

and below you can see the read operation from the TCAN4550: 

masterTxBuffer[0] = 0x41;
masterTxBuffer[1] = 0x00;
masterTxBuffer[2] = 0x00;
masterTxBuffer[3] = 0x2; 
memset((void *) masterRxBuffer, 0, SPI_MSG_LENGTH);
transaction.count = 12;
transaction.txBuf = (void *) masterTxBuffer;
transaction.rxBuf = (void *) masterRxBuffer;

/* Toggle user LED, indicating a SPI transfer is in progress */
GPIO_toggle(CONFIG_GPIO_LED_1);

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

below you can see a SCOP picture of full plot of the all the transmitted 12 bytes.  Yellow: MISO, Red: MOSI, Blue: CS, Green: CLK

attached below picture of the same transaction connected logic analyzer on SPY mode listen only:

SPI generator LAB tool, generate the SPI signal note: the CC1352 is disconnected:

write from the tool the next SPI transaction 0x41 0x0 0x0 0x2, and read  Read: 4E, 41, 43, 54, 30, 35, 35, 34,

as we expected from the TCAN4550 DS

SCOP picture Yellow: MISO, Red: MOSI, Blue: CS, Green: CLK

the next picture full span in order to see all the transaction, it is looks much longer than the CC1532 and there is bigger space between the CS and to the first write.

zoom in to the write :

zoom in to the read 

thanks!

I saw that there are some pictures that did not upload/attached well, I will try to resend only them again

from last massage:

"

attached below picture of the same transaction connected logic analyzer on SPY mode listen only:

SPI generator LAB tool, generate the SPI signal note: the CC1352 is disconnected:

write from the tool the next SPI transaction 0x41 0x0 0x0 0x2, and read  Read: 4E, 41, 43, 54, 30, 35, 35, 34,

as we expected from the TCAN4550 DS

"

thanks

Hi, 

any update?

thanks

Meron,

Thanks for your patience here and sorry for the delay. We'll have a response for you next week.

Regards,

Hi Meron,

Eric asked me to help out with this post.  I have the same SPI lab tools you are using and I use them regularly with the TCAN4550.  The long delay between the CS signal and the data seen when using your SPI lab tool is because the tool controls the CS line with a separate software command than the rest of the SPI pattern data.  This results in separate USB commands being sent to the tool, one to set the CS line low, one for the SPI data, and one to set the CS line high again.  I've seen about 7 to 10 mS of delay on my PC, but this is not a problem.

The problem appears to be with how the CC1352 is toggling the CS line after every 8 bits.  The TCAN4550 requires a 32 bit word for each SPI transaction and it actually counts the number of clock cycles between the CS transitions.  If there are not an exact multiple of 32 bits (i.e. 32, 64, 96, 128, etc.) then it assumes an error has occurred and the data is invalid. 

If it was a "write" command, the data incoming data is discarded and the SPI Error (SPIERR) flag is set to inform the MCU of the error.  If it was a "read", the device will not respond, or respond completely, and it will set the SPIERR flag as well to inform the MCU that the last transaction may contain errors.

While I'm not familiar in the CC1532 SPI Master code, it appears that the MCU is going to transition the CS line at the beginning and end of each "transaction" and it is using 8bits for each transaction.  If you tell it to perform 12 transactions, because you are transferring 12 bytes of data, then it will toggle the CS line 12 times as shown in your scope plots.

What you need to do is find the function that controls the CS line in each transaction and you need to modify this function to prevent it from toggling. 

Then you need to essentially mimic your SPI lab tool and create a new function that simply toggles the CS line low (I'll call it "CS_Low()"), and a separate function that toggles the CS line high which I will call "CS_High()".  Or you could do a single function such as CS_Toggle(state) and pass it a 1 or 0, etc.

Then in your code, you will need to:

1.) Call the CS_Low() function to start the transaction

2.) Call all your SPI data related functions for the 32-bit words you want to write or read

3.) Call the CS_High() function to end the transaction.

Since you have proven communication with your SPI lab tool, you can use it as a reference to make your MCU code match the waveforms.  As long as there is an exact multiple of 32bits between CS, you should have success.

Regards,

Jonathan

Hi,

we need your help ASAP.

we need to know where to change the code in order to control the CS.

thanks,

Hi Meron,

We have contacted someone from the CC1532 team to help out with instructions on how to adjust the chip select.  We will follow up soon.

Regards,

Jonathan

May I ask if any further investigation is done? We are currently considering CC1352R with TCAN4550.

Henrik,

I'm contacting the EP team now to see if they can post how to adjust the chip select function of the CC device since that seems to be the root cause of the issue here.

Regards,

Eric Hackett 

Hi Henrik,

Apologies for the delay. We will try and find an explanation for you next week when the team is back from Easter leave.