Top

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: 1

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 7 times
yangjie
Posts: 205

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.

Post Reply