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 220.127.116.11 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?
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/d5f9b84c3f9ce4048cdb642313f12cf700394…
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)
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.