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

PSoC™ 5, 3 & 1 Forum Discussions

Len_CONSULTRON
Level 9
Level 9
500 solutions authored 1000 replies posted 750 replies posted

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);

...

}

Len
"Engineering is an Art. The Art of Compromise."
0 Likes
1 Solution

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:

ILO Frequency.PNG

View solution in original post

0 Likes
5 Replies
Len_CONSULTRON
Level 9
Level 9
500 solutions authored 1000 replies posted 750 replies posted

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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:

ILO Frequency.PNG

0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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.

Colley,

Good suggestion.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes