From: Christoph Niedermaier Sent: Monday, December 13, 2021 5:16 PM >>>>> Thanks anyway, so now I know it must be >>>>> problem with my DA9061 chip. >>>>> >>>>> @Adam >>>>> Where can it come from? >>>>> Can you give we a hint what to check? >>>> >>>> I've spoken internally and have been informed that this is down to the fact that >>>> DA9061 runs only from an internal oscillator which may be slower. The indication >>>> is that the values for TWDSCALE describe the window where if a kick/ping occurs >>>> within that period then the watchdog is guaranteed *not* to timeout. The actual >>>> timeout would be at some point after the selected timeout period, assuming no >>>> ping/kick occurred. >>>> >>>> Table 8 in the datasheet specifies a minimum watchdog timeout of 2.5s (tWDMAX) >>>> under specific operating conditions, so if the minimum 2s window was chosen >>>> (TWDSCALE = 1) then earliest the watchdog would actually timeout, following a >>>> ping, is 2.5s, assuming the conditions matched those described. >>>> >>>> If you have further questions it probably makes sense to contact Dialog/Renesas >>>> support as they will be able to provide more detailed info on this. >>> >>> So a DA9061 runs only from an internal oscillator, whereas a DA9062 >>> can run on either an internal or an external oscillator. So this >>> means that the DA9061 timeout values are differ from the DA9062 >>> with an external oscillator not only on my device but on all DA9061 >>> devices. >>> >>> This are the values (in seconds) in comparison: >>> DA9062 (from driver): 0 2 4 8 16 32 65 131 >>> DA9061 (measured): 0 3 6 12 25 51 102 204 >>> ================================================= >>> Difference: 0 +1 +2 +4 +9 +19 +37 +73 >>> >>> In my opinion, the differences in the higher values are very huge. >>> If I expect that the watchdog triggers and I have to wait more than >>> a minute for that to happen I ask myself is there something wrong. >>> >>> @Andrej >>> I guess, you are using an external oscillator, aren't you? >>> >>> @Adam >>> Is there a way to check in the driver which oscillator is in use? >>> >>> @Maintainers >>> Is in the driver a need to distinguish between an external and an >>> internal oscillator to get the timeout values more accurate? >>> >> >> It would be very desirable to get timeout values more accurate. >> I would not want to dictate how to implement it, though. >> It could be automatically detected if that is possible, there >> could be a devicetree clock property providing the clock >> frequency, or maybe there is some other solution. >> >> Guenter > > I am open for a good solution. > Meanwhile I measured the timeout values of my 8 available DA9061 > watchdogs. I derived the following formula from the given formula > at the data sheet and the clock divider of 2^16: > > f = 2^(15+TWDSCALE) / t > > Formula check with the external oscillator (32kHz) TWDSCALE=7 @ 131s: > f = 2^(15+7) / 131 = 32017Hz (=> should be OK) > > The timeouts of my 8 watchdogs (9061-AA) with TWDSCALE=7: > t7 = 211s => 19878Hz > t7 = 197s => 21291Hz > t7 = 203s => 20662Hz > t7 = 204s => 20560Hz > t7 = 206s => 20361Hz > t7 = 198s => 21662Hz > t7 = 200s => 20972Hz > > According to the data sheet the internal oscillator should run at 25kHz. > The average frequency of my 8 devices is 20.6kHz. Maybe the data sheet > Clock value is a max value. The timeout difference on my 8 devices are > 14s. So the values vary from device to device, and maybe there is also a > temperature component. > > @Adam > Is there a way to check which oscillator is in use? > Is there a way to find the current oscillator frequency? > Are there any other ideas/solutions to get the timeout values more accurate? As I sent my E-Mail I didn't see your answer, so here it is: > A quick scan of the DA9062 datasheet shows that reg/field EN_32K/CRYSTAL will > indicate the presence of a 32KHz crystal oscillator. Obviously on DA9061 that > option isn't available. > > I think the problem seems to lie around determining the internal oscillator's > frequency. Datasheet references 25Mhz in Table 9 (Watchdog Electrical > Characteristics), but that doesn't seem to tally with your timings and I don't > see an obvious way in the regmap to calculate this at run time. *If* the > oscillator frequency varies from part to part, or under different environmental > conditions, then it's going to be tough to tie this down, and you wouldn't want > to state a timeout value that's longer than reality. @Adam What do you think if I add also the timeout values for the internal oscillator? Than the values would be: t = 2^(15+TWDSCALE) / f Internal 25kHz oscillator: 0 2 5 10 20 41 83 167 In comparison to the external 32kHz oscillator: 0 2 4 8 16 32 65 131 So the difference to my measured values will decrease and it will improve the current driver towards more accurate values. Btw if I calculate the values with 32768Hz (the typical 32kHz oscillator), I get the following values: 32768Hz oscillator: 0 2 4 8 16 32 64 128 Regards Christoph