Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

USB superspeed peripherals Forum Discussions

OlJo_4577026
Level 2
Level 2

The FX3 documentation (SDK version 1.3.4) for CyU3POsTimerInit claims that the default timer tick interval is 1ms.

This does not match the implementation. The actual tick interval is around 0.976ms (250/256 ms). This means that all delays, timeouts, and so on are slightly too fast. It adds up to human-visible differences fairly quickly, I could easily verify the difference by hand with a stopwatch. You can also see this effect by comparing the values returned by CyU3PGetTime() to the values returned by CyU3PGpioComplexSampleNow() on a complex GPIO configured for a known frequency.

The underlying cause of this is that the timer interrupt handling in system/cyu3vic.c appears to assume that the watchdog clock runs at exactly 32.000kHz. But the hardware actually runs this clock at 32.768kHz per the TRM.

Workaround: scale all delays and timeouts passed to the firmware by 256/250. Scale the return value of CyU3PGetTime() by 250/256.

Any plans to fix this in the firmware library? It's possible to get the average tick interval much closer to 1ms (I prototyped a fix and with a little fixed-point math got the average error down to < 1ppm fairly easily). Failing that, the documentation needs to be updated to reflect that ticks are not 1ms.

0 Likes
1 Solution

Hi!

I'm using the default setup of the development board which I believe uses the internal WDT clock.

Can you update the documentation to indicate the correct default value? I appreciate that 1ms is within 4% of the actual value, but given that you know the exact actual value (0.976ms), the current documentation which claims that the default is 1ms is a bit misleading.

I've added the patch I used to correct the timing to the github gist linked above: https://gist.githubusercontent.com/mutability/ea02e61d522f8f5102af5fe62f4f4951/raw/d5f9b84c3f9ce4048...

This patch varies the programmed watchdog count by +1 periodically to achieve the correct average rate. While the duration of individual ticks is still limited by the underlying clock rate - individual ticks are still either 0.976ms or 1.007ms - the average rate of ticks is very close to 1000Hz. So, for example, CyU3ThreadSleep(60000) delays for 58.5 seconds with unpatched firmware, but delays for 60.0 seconds with the patch.

(I found the value used for CY_U3P_OS_TIMER_TICK_OFFSET empirically)

View solution in original post

0 Likes
4 Replies
OlJo_4577026
Level 2
Level 2

Here is demo code showing the problem: Measure Cypress FX3 timer tick period / errors · GitHub

0 Likes

Hi,

Thank for pointing out the issue to us.

However, we are already aware of the issue and have already been mentioned in the FX3ApiGuide.pdf

Please go through 5.27.12.54 void CyU3POsTimerInit ( uint16_t intervalMs ) API in the FX3ApiGuide.pdf

The API documentation states, " The actual tick interval can have an error of upto +/- 4%."

The issue comes because of the software limitation for the Watch Dog Timer limitation which is derived from the 32KHz standby clock.


I really appreciate the efforts you have put to bring this to us and thanks for the demo code as well.

Could you please be kind to share the prototyped fix where you brought the timing down to <1ppm?

Also, are you using an external or internal Watch Dog Timer clock supply?

Regards,

Yashwant

0 Likes

Hi!

I'm using the default setup of the development board which I believe uses the internal WDT clock.

Can you update the documentation to indicate the correct default value? I appreciate that 1ms is within 4% of the actual value, but given that you know the exact actual value (0.976ms), the current documentation which claims that the default is 1ms is a bit misleading.

I've added the patch I used to correct the timing to the github gist linked above: https://gist.githubusercontent.com/mutability/ea02e61d522f8f5102af5fe62f4f4951/raw/d5f9b84c3f9ce4048...

This patch varies the programmed watchdog count by +1 periodically to achieve the correct average rate. While the duration of individual ticks is still limited by the underlying clock rate - individual ticks are still either 0.976ms or 1.007ms - the average rate of ticks is very close to 1000Hz. So, for example, CyU3ThreadSleep(60000) delays for 58.5 seconds with unpatched firmware, but delays for 60.0 seconds with the patch.

(I found the value used for CY_U3P_OS_TIMER_TICK_OFFSET empirically)

0 Likes

Hello,


Thank you for you valuable inputs regarding the topic.

We will notify the concerned teams to try and rectify the issue as soon as possible.

Regards,

Yashwant

0 Likes