This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3235MODSF: In SPI host mode, start the TX and RX channels to connect to DMA, and get stuck after calling sl_send.

Part Number: CC3235MODSF
Other Parts Discussed in Thread: CC3200

Hi team,

Here's the request from the customer:

Developing with CC3235MODSF, SPI adopts master mode, data width is two bytes, both tx and rx channels are connected to DMA (dual DMA channels), run WIFI-AP mode on tirtos system. Calling sl_Recv to receive host computer data through DMA and transmitting by SPI, the data received by SPI DMA is sent to the host computer through sl_Send.

Customer's question is When the packets he sent and received are small, there is no problem, the whole process is smooth. When the data increased to 1460 bytes a packet (DMA size is set to 1460 bytes), SPI transmitted is normal, but the SPI RX DMA got stuck after receiving a packet of 1460 and then calling sl_Send. The program was stuck waiting for the second packet of 1460 to be received. The second trigger of SPI-RX-DMA had no response, and the SPI was not working. After testing, as long as sl_Send is not called, the SPI RX DMA can work smoothly. The sl_Send function is blocking and waiting, which means that he starts calling SPI RX DMA after ensuring that sl_Send has sent 1460 bytes, but the result was still stuck.

The same code is no problem on the CC3200 with freertos. How to deal with it?

Could you help check this case? Thanks.

Best Regards,                                                            

Nick    

  • Hi Nick,

    I need some more clarification. sl_send and sl_recv are the WiFi commands. Are you saying that this data is sent over to the host computer by WiFi or hardwired through SPI?

    Could you please an example code of the issue so that I can debug it and understand what is going on?

  • Hi Sabeeh,

    The SPI is hardwired connected to another device, and CC3235 is the master; then a TCP socket is established, SimpleLink is used, and CC3235 is used as AP.

    The realized function is to cyclically receive SPI data and send it through sl_send to the site, which is a network debugging tool on the computer. Then the bug customer encountered was the one he described above

    Best Regards,                                                            

    Nick    

  • Hi Sabeeh,

    May I know is there any update for this question?

    Best Regards,                                                            

    Nick   

  • Why is the SPI DMA waiting for a second block of 1460 bytes? Was there an error on the sl_send?

    If customer removes sl_send, what would happen? Does the SPI receive data reliably? It sounds to me like an interrupt was not set somewhere.