6 Replies Latest reply on Feb 18, 2020 7:35 AM by JoBu_4538421

    Wiced time functions break hardware timers?

    JoBu_4538421

      Hello,

       

      I am using a LAIRD Sterling EWB development board with WICED SDK.

       

      board part number: 455-00030

      SDK Version: WICED-SDK Version: Wiced_006.004.000.0061

       

      I am using a hardware timer peripheral (Timer 2) of the STM32F4 as a microsecond counter. This counter increments a variable every microsecond through the use of an interrupt. It appears that WICED timing functions prevent the interrupt from being triggered as it should. This has been tested with ThreadX as the RTOS.

       

       

      I created a simple 10s delay routine using the timer peripheral and used a stop watch on my phone to verify:

       

       

      In this case, everything works as expected. timeDifference shows roughly the number of microseconds equal to 10 seconds.

       

      However, when the delay routine is replaced with wiced_rtos_delay_milliseconds(10000), my stop watch verifies that the program takes 10s to run, but the values returned by the microsecond counter are roughly 1/3 of the actual time:

       

       

      timeDifference is now showing 1/3 the number of microseconds equal to 10 seconds. Why would the wiced function cause such a difference in the results of the timer 2 module? Is it possible that wiced is preventing interrupts from executing? The same problem occurs whenever an RTOS timer is used instead of a delay.

       

       

      Here is the initialization of the timer 2 module along with the elapsed time function:

       

      Here is the definition for the timer 2 interrupt:

       

      Ultimately, we would like to use the timer2 module as well as RTOS timers without the RTOS timers affecting the timer 2 module. Is there a way to do that?

       

      Please let me know if you have any questions or comments.

       

      Thanks,

      John

       

        • 1. Re: Wiced time functions break hardware timers?
          ZhengbaoZ_96

          hello:

           

            timeDifference is now showing 1/3 the number of microseconds equal to 10 seconds.

          From this description,  rtos_delay 10000ms  is accurate ,  but the m_nHighResolutionCounter in the timer2 ISR is only 1/3 , it this right ?  I do not think hardware interrupt was blocked, but ISR function may be blocked in the running.

          1 of 1 people found this helpful
          • 2. Re: Wiced time functions break hardware timers?
            JoBu_4538421

            Hello,

             

            You are correct that m_nHighResolutionCounter is only 1/3 of what it should be. I'm not sure why that is, but your suggestion of the ISR being blocked sounds right. Is there something else I should do to ensure that m_nHighResolutionCounter has the correct value after the wiced_rtos_delay_milliseconds(10000)?

             

            Thank you for your response,

            John

            • 3. Re: Wiced time functions break hardware timers?
              ZhengbaoZ_96

              hello:

                  We have a setting API in platform.c 

              platform_init_peripheral_irq_priorites(void) , but all the value is bigger than 0 ,  0 is the highest priority .

              My suggestions are :

              1.  maybe you can add the priority setting into this table from the platform_init_peripheral_irq_priorites .

              2.  Can we have a chance to set the TIM2 timer to 10us every INT ? then we can calculate the error ratio.

              1 of 1 people found this helpful
              • 4. Re: Wiced time functions break hardware timers?
                RaSc_1712766

                John,

                 

                In the case where the code worked as expected, there’s a busy loop in the application polling the value, so the processor is running continuously, not sleeping.

                 

                In the case where the code doesn’t work, the call to the wiced_rtos_delay_milliseconds() will cause the task to sleep, possibly putting the processor to sleep if there was nothing else going on. This could cause increased interrupt latency and therefore missed interrupts.

                 

                If any of the sleep modes of the STM32F412 are being used (sleep or STOP) and based on how the processor is configured, there is a defined wakeup time in the datasheet. These values are typically in the 10's of microseconds. Since you're expecting that your interrupt executes every microsecond, any low power mode will cause you to miss interrupts and you'll see a lower count than you expect.

                 

                Slowing the timer down, as suggested by Zhengbao may help, however depending on how much interrupt latency there is, 10 microseconds may still be too fast to avoid missing any interrupts.

                 

                If you are really just in need of a microsecond counter, I would configure TIM2 to count once per microsecond (using the prescaler) and using the value of the timer's counter itself to replace your m_nHighResolutionCounter. That is, let the hardware do this for you and don't bother with the interrupt handler.

                 

                Randy.

                2 of 2 people found this helpful
                • 5. Re: Wiced time functions break hardware timers?
                  ZhengbaoZ_96

                  Hello Randy:

                   

                  That it great, thanks for the reply:   Let the hardware do this for you and don't bother with the interrupt handler .

                  • 6. Re: Wiced time functions break hardware timers?
                    JoBu_4538421

                    Hi Randy,

                     

                    Using the hardware timer's counter directly is a much better solution. Thank you very much

                     

                     

                    John