the SPI communications “hangs” randomly-urgently

Wi-Fi devices, Wi-Fi low power devices, Wi-Fi BLE dual-mode devices, Ethernet devices, Ethernet+Wi-Fi devices and so on.


Post Reply
ryan.yu@boneco.ch
Posts: 4

the SPI communications “hangs” randomly. Please find attached the analysis of the problem and the modified tuya_app_main.c from the quickstart demo. can you check this on a T2 Demo Board and can you run the spi in a Loop for a few minutes at least and with the function “tkl_spi_transfer(SPI_ID, spi_send_buffer, spi_rcv_buffer, SPI_BUFFER_LEN))”!
you just can run my example program in the quickstart demo then the problem should be seen after a while.

Attachments
1726647029369.png
1726647012242.png
tuya_app_main.c
(15.86 KiB) Downloaded 77 times
yangjie
Posts: 209

Re: the SPI communications “hangs” randomly-urgently

What do you want to use the SPI driver for? The T2 SPI driver needs to pay attention to a few things:

  1. If spi sends more than 4,096 bytes, a dma interrupt is used, which calls tkl_spi_set_spic_flag() after tkl_spi_init().

  2. If an interactive interface is used, that is, tkl_spi_transfer(SPI_ID, spi_send_buffer, spi_rcv_buffer, SPI_BUFFER_LEN); It is recommended to use the spi interrupt, that is, not tkl_spi_set_spic_flag();

  3. You can determine if the spi was successful by using tkl_spi_get_status() to get the SPI status. Let's just assume that yes, it's always successful and try to see if this problem still occurs.

  4. For the spi configuration, you can try the following configuration, the recommended T2 SPI clock frequency is 1M-8M.

    Code: Select all

      TUYA_SPI_BASE_CFG_T cfg;
    
      cfg.role = TUYA_SPI_ROLE_MASTER;
      cfg.mode = TUYA_SPI_MODE0;
      cfg.type = TUYA_SPI_AUTO_TYPE;
      cfg.databits = TUYA_SPI_DATA_BIT8;
      cfg.bitorder = TUYA_SPI_ORDER_LSB2MSB;
      cfg.freq_hz = 8000000;
      cfg.spi_dma_flags = 1;
    
  5. One problem with using the SPI interrupt on T2 (that is, not calling tkl_spi_set_spic_flag()) is that when there is a large amount of data, the SPI interrupt may arrive early, that is, the SPI interrupt is received before the data has been received, resulting in data loss.

As for the example you provided, I checked the overall call flow is correct and there is no problem. You can follow the tips above to make changes.

ryan.yu@boneco.ch
Posts: 4

Re: the SPI communications “hangs” randomly-urgently

thanks very much for your propose.
It was a little confusing. But we have found a solution, The program is working but in hardware it does NOT work, because the Chip-Select Pin does not work correct. could you please give some advise for us, thank you

/spi init/
STATIC TUYA_SPI_BASE_CFG_T spi_cfg = {
.mode = TUYA_SPI_MODE0,
.freq_hz = SPI_FREQ,
.databits = TUYA_SPI_DATA_BIT8,
.bitorder = TUYA_SPI_ORDER_LSB2MSB,
.role = TUYA_SPI_ROLE_MASTER,
.type = TUYA_SPI_AUTO_TYPE,
.spi_dma_flags = 1}; // <-- Set spi_dma_flags = 1 is important for successful work of the SPI unit!

Code: Select all

TAL_PR_NOTICE("SPI Gatekeeper init ...");
/*spi init*/
tkl_spi_set_spic_flag(); // <--Call tkl_spi_set_spic_flag() is important before calling tkl_spi_init()
TUYA_CALL_ERR_LOG(tkl_spi_init(SPI_ID, &spi_cfg));

These two modifications seem to work. The function tkl_spi_set_spic_flag() is not public in tkl_spi.h and not documented well. If one call this function after tkl_spi_init() it has no effect. Now also the data_loss flag and the mode_fault flag received from tkl_spi_get_status(SPI_ID, &spi_status) are now 0. They where always 1 before the change.
I have run the demo program for more than 100 000 loops without error.

[09-23 17:53:23 ty E][tuya_app_main.c:495] tkl_spi_transfer OK
[09-23 17:53:23 ty D][tuya_app_main.c:496] spi status: b:0 l:0 f:0 cnt: 111872

ryan.yu@boneco.ch
Posts: 4

Re: the SPI communications “hangs” randomly-urgently

we found the following comment in the file “software/TuyaOS/vendor/t2/beken_os/beken378/driver/spi/spi_master_bk7231n_new.c”:

// 全双工收发接口,也可仅发送或仅接收
//存在问题,收发同时时,接收会丢掉一个字节,在2M频率下
int bk_spi_master_dma_xfer(struct spi_message *spi_msg)

This function is call by tkl_spi_transfer(SPI_ID, spi_send_buffer, spi_rcv_buffer, SPI_BUFFER_LEN), the function that I use to transfer data.

Could you please check if this is a problem, thank you

yangjie
Posts: 209

Re: the SPI communications “hangs” randomly-urgently

  1. If you have only one slave mounted on your spi, use pin 15 as cs. cfg->type is TUYA_SPI_AUTO_TYPE.
    The T2 SPI pin is as follows:

    Code: Select all

    //   SCK -----> 14
    //  MOSI -----> 16
    //  MISO -----> 17
    //   CS  -----> 15
    
  2. T2 SPI does not support full duplex, you need to use half duplex
ryan.yu@boneco.ch
Posts: 4

Re: the SPI communications “hangs” randomly-urgently

but every SPI can transfer data in full duplex. we final have found the problem in the Tuya System and could manage to apply a solution that works for us. Please find attached the updated document. could you please check and change the TUYA System as well? thank you

Attachments
4.png
1.png
2.png
3.png
Post Reply