LAUNCHXL-F28379D: F28379D-LaunchPad and CC3220SF via SPI protocol

Hi Carlo,

Per the customer's write-up, the issue seems to be with the CC3220 code. We will get this over to the right forum.

Hello Gus,

Thank you for looking into this, please help in moving the query to the appropriate forum.

Regards,
Carlo

Hi Carlo,

Does the customer have a logic analyzer so we can capture what is happening during the transfer?

Best regards,

Sarah

Hello Sarah,

According to our customer, he just tried the Saleae logic analyzer software but it seems like it needs the Saleae Logic hardware itself. Do you have a recommendation for any logic analyzer software that he can use without logic analyzer hardware that supports TI boards?

Regards,
Carlo

Hi Carlo,

Unfortunately, no.

If he has another CC32xx LaunchPad, he can test the default spimaster and spislave examples and verify he's able to receive data.

Best regards,

Sarah

Hello Sarah,

Our customer have already tested the spimaster and spislave project examples in CCS using 2x CC3220SF boards. They were able to exchange data (send and receive) with each other. The main problem of our customer is stated below:

"I don't know which code segment should I modify in the spislave example so that it would receive data from the F28379D LaunchPad using MATLAB Simulink. I'm trying to send data from F28379D (MATLAB Simulink) to CC3220SF (CCS) without using the handshake event (is it possible?). I've set the SPI parameters of CC3220SF in CCS spislave example to match with the F28379D's configuration in MATLAB Simulink however, it still doesn't receive anything from the F28379D board. "

Please see the previously attached document for the code.
Regards,
Carlo

Hi Carlo,

The GPIO handshake is not required for the driver, it is part of the demo. If he does not want to use it, he can first remove it from the spislave and spimaster test to verify it was done correctly. Then I suggest testing with the data format he will be sending the CC3220.

If the customer can do both those things, then they should check the data coming from the master.

Best regards,

Sarah

Hello Sarah,

I received an update from our customer as follows:

"I've tried connecting 2x CC3220SF earlier without the handshake event but I'm not yet successful. Maybe for that one, I'll just go with having a handshake event when connecting C2000 (MATLAB) and CC3220SF (CCS). But still, I haven't identified how to fix the main problem."

Thank you for your help on this.

Regards,
Carlo

Hi Carlo,

If they leave in the handshake, is the customer able to send and receive the right data format using the two CC3220 LPs? This will verify that the hardware is set up correctly and he has set up the buffers correctly.

A common thing to check is if they are setting the correct bit rate and other parameters in SPI_Params.

I also see in the C2000 setting, they have enabled high speed mode. I'm unfamiliar with the C2000 settings, but they should verify this setting is compliant with the peripheral requirements in the CC3220 datasheet and Technical Reference Manual.

Best regards,

Sarah

Hello Sarah,

Our customer was able to send and receive the correct data using 2x CC3220SF LPs. The customer will conduct further testing about this. Thank you.

Regards,
Carlo

Hello Sarah,

In this code for the receiving side in Code Composer Studio, if the C2000 device was able to send a value to the SPI, is this line of code from the CC3220SF (slave):
transaction.rxBuf = (void *) slaveRxBuffer;
stores the transmitted data then display it using the Display_printf() function?
Regards,
Carlo

Hi Carlo,

transaction.rxBuf must be given a buffer to copy the received data into. You can see a few lines earlier that slaveRxBuffer is being cleared with memset(). Later, the contents of the buffer is printed.

slaveRxBuffer is defined at the top of spislave.c. Once a transfer begins, this buffer cannot be touched until the transfer is complete or cancelled.

Best regards,

Sarah

Hello Sarah,

Thank you so much for your help. Please see the attached file for the response of our customer. The Matlab code is also provided in the file.

CCS Matlab Code.docx

Regards,
Carlo

Hi Carlo,

It looks like the customer is receiving data on the CC32xx, but the question is finding the right format with Matlab. Unfortunately, I do not have any insight into this.

The customer can try debugging to determine the contents of the Rx buffer. Based on the hex value in the terminal, it is also possible they are printing the memory location of the buffer instead of the buffer contents. Please verify that using the debugger.

Best regards,

Sarah

Hello Sarah,

Our customer was able to send and receive the accurate value from MATLAB to CCS. Here are the details provided.

The C2000 is sending the value '88' to CC3220SF which is equivalent to 'X' and it was accurately received by CC3220SF however, it appears that C2000 was able to send 2 '88' values before the CC3220SF can receive and display it. Please see the image as a reference.

Do you know any way to have the transmission and receiving in-sync with both devices? Also, I've tried removing the TxBuffer on SPI transaction so that the CC3220SF only receives a value because it doesn't need to transmit any data to the master back but when I remove it, the slave code won't able to receive anything. Is it possible to remove the transmitting part in slave device so it just receives anything from the master? If possible, could you please tell me how to do that?

Thank you for the help.

Regards,
Carlo

Hello Sarah,

Our customer was able to solve the problem. They've been able to exchange the intended values in 1:1 ratio now. According to our customert it appears that the problem is with the transaction.count value which should be 1 instead of 2 since they just sending 1 sample per time x. Your response with the count parameter gave the customer the idea and it worked.

Thank you so much for the help and assistance.

Regards,
Carlo