- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm using a PSoC 5LP and FreeRTOS. I developed an app that is working. I tried to add a WDT service as a separate task. The task never appears to clear the WDT and therefore goes into RESET constantly. Am I missing something?
Code frag:
WDT_DELAY 2000 // the delay between 'petting' the WatchDogTimer
wdt_task(void *arg)
{
CyWdtStart(CYWDT_1024_TICKS,CYWDT_LPMODE_DISABLED);
for(;;)
{
CyWdtClear(); // 'pet' the WDT
vTaskDelay( pdMS_TO_TICKS( WDT_DELAY)); // delay before the next 'petting'
Pin_LED_BLUE_Write(!Pin_LED_BLUE_Read()); // Toggle the LED for visual indication
}
}
main()
{
...
xTaskCreate(wdt_task,"WDT_TASK",50,NULL,5,&wdt_task_handle);
...
}
"Engineering is an Art. The Art of Compromise."
Solved! Go to Solution.
- Labels:
-
PSoC 5LP
- Tags:
- wdt psoc5 freertos
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Near as I can tell, 1.82 seconds is within tolerance. The nominal value is 2.05 seconds, but that has a -50% to +100% tolerance due to the tolerance on the ILO frequency.
This is from the CY8C58LP family datasheet:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To all,
Here's an update:
If I disable ALL the other tasks (ie. Comment out the line that creates the tasks) which prevents these tasks from running, the CPU RESETs after two WDT_DELAY times (=4000 msecs).
If I set WDT_DELAY to 1500 msec, The wdt_task() works and I avoid a RESET. This is even true if I reactive the other tasks (ie. uncomment out the TaskCreate()s for this tasks.).
Update: I can set WDT_DELAY to 1820msec and have it work. Above 1820, it appears to clear the WDT on the first time in the for(;;) loop but not the second time.
Question: If I set the WDT to CYWDT_1024_TICKS, the CWT should be allowed to be cleared at least every 2000 msec without reset. In the above test, 1820msec worked, 1825msec did not.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Near as I can tell, 1.82 seconds is within tolerance. The nominal value is 2.05 seconds, but that has a -50% to +100% tolerance due to the tolerance on the ILO frequency.
This is from the CY8C58LP family datasheet:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mr Colley,
I believe you may have spotted the issue.
The task scheduler is using the IMO clock with +/- 1% accuracy for the Ticks (actual accuracy measured = 0.3%).
The WDT ONLY uses the ILO origin clock of 1KHz -50%/+100% accuracy as you noted. (actual accuracy measured = +20%).
You're answer reminded me that I'm using two asynchronous clocks with widely differing resolutions.
I can use the lower WDT_DELAY value of 1500msec. If I needed to improve the accuracy of the ILO clock, I can use the IMO clock as a reference. The "ILO_Trim" component claims 1KHz +/- 10% accuracy. Right now there's no immediate need.
Thanks for the insight.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's better practice to run the WDT and the processor from separate clocks.
If you run the WDT from the IMO clock and somehow your code erroneously stops the IMO clock, the WDT also stops and you don't get reset.
The WDT interval can go as low as 1.024 s at max ILO frequency. Derate that by 0.99 to account for the tolerance on the IMO. That leaves you with a maximum reliable value for WDT_DELAY of 1013.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Colley,
Good suggestion.
Len
"Engineering is an Art. The Art of Compromise."