3 Replies Latest reply on Nov 20, 2019 12:34 AM by YoTa_1693656

    CYW20819/ SPP Library API call sequence

    YoTa_1693656

      Hello Cypress IoT team

       

      We evaluate SPP transfer with the attached code "spp.c".

      If they comment out following codes, CYW20819 aborts the transfer and looks like hang up.

      -Line 284: wiced_rtos_delay_milliseconds(5, ALLOW_THREAD_TO_SLEEP);

      -Line 285: wiced_rtos_set_event_flags(eventHandleSppTx, EVENT_SPP_TX_BUFF_WR);

       

      [Question]

      Do you know why CYW20819 abort the transfer? If there is any limitation, let me know.

       

      [Our exptected behavior when comment out above codes]

      1. The thread "threadFunctionSppTx" is event waiting state at "wiced_rtos_wait_for_event_flags".

      2. Consider earch thread priority .

      3. The thread "threadFunctionGenTx" is called and generates 1byte Tx Data.

      4. The thread "threadFunctionSppTx" is called again by "wiced_rtos_set_event_flags".

      5. "wiced_bt_spp_can_send_more_data" is called in The thread "threadFunctionSppTx".

      6. Repeat step 1.

       

      Thanks,

      Yoshinori

        • 1. Re: CYW20819/ SPP Library API call sequence
          DheerajP_41

          Hi,

           

          When your thread's stack size is high then chances are there for running out of stack which can cause erratic, difficult to debug behavior. Using 1024 is overkill.

          Also cyclic dependencies in your code can also cause deadlocks.

           

          Unfortunately, the device did not advertise also for me with your code.

           

          Thanks.,

          -Dheeraj

          • 2. Re: CYW20819/ SPP Library API call sequence
            YoTa_1693656

            Hello Dheeraj-san

             

            Thank you for your advice.

            To narrow down this phenomenon, we tested single thread with attached source codes.

            =====

            <spp_20191112a.c>

              If "wiced_bt_spp_can_send_more_data" returns FALSE, it is called repeatedly.

            Result:

            CYW20819 aborts SPP transfer on the way then hangs up. (It looks like No response from CYW20819.)

             

            <spp_20191112b.c>

              If "wiced_bt_spp_can_send_more_data" returns FALSE, it is called repeatedly until a limitation defined as "MAX_OCCUPATION_TIME".

              Then, the thread is released by "wiced_rtos_delay_milliseconds".

            Result:

            If MAX_OCCUPATION_TIME is 50 msec, CYW20819 completes SPP transfer.

            If MAX_OCCUPATION_TIME is 100 msec, CYW20819 aborts SPP transfer on the way then hangs up.

            ======

            From those results, we guess the hung up phenomenon depends on the thread occupation time. How do you think?

             

            Thanks,

            Yoshinori

            • 3. Re: CYW20819/ SPP Library API call sequence
              YoTa_1693656

              Hello Dheeraj-san

               

              We conducted an additional test to narrow down this issue. The source code is attached.

              If we add "wiced_hal_wdog_disable()", CYW20819 does NOT hung up and completes the SPP transfer.

                   Line 334 wiced_hal_wdog_disable();

               

              1) We suspect that CYW20819 hangs up when the watch dog timer(WDT) expire timeout. Is it correct?

              2) If 1) is correct, let me ask following questions.

              2-1) Do you know recommended way to reset the WDT?

              2-2) According to API Reference Guide, timeout value of the WDT is 2sec. But actual timeout value looks like 4 sec under our test. Is it correct?

               

              Thanks,

              Yoshinori Takano