Not applicable
Jun 18, 2012
02:43 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 18, 2012
02:43 AM
[quote=Section 9.1: Watchdog Timer - Functional Description]
If the WDT is not serviced before the timer overflows, a system malfunction is assumed
and normal mode is terminated. A WDT NMI request (FNMIWDT) is then asserted and
prewarning is entered. The prewarning lasts for 30H count.
I am wondering, is that 0x30 low byte or high byte? It's the difference between 4 or 256µs
and 1.024 or 65.536ms for me.
A lot can be accomplished in 1ms. I doubt I can do a lot of useful stuff in 4µs.
If the WDT is not serviced before the timer overflows, a system malfunction is assumed
and normal mode is terminated. A WDT NMI request (FNMIWDT) is then asserted and
prewarning is entered. The prewarning lasts for 30H count.
I am wondering, is that 0x30 low byte or high byte? It's the difference between 4 or 256µs
and 1.024 or 65.536ms for me.
A lot can be accomplished in 1ms. I doubt I can do a lot of useful stuff in 4µs.
Labels
- Labels:
-
XC800
5 Replies
Not applicable
Jun 18, 2012
03:41 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 18, 2012
03:41 PM
Here are my findings, it's definitely the high byte, which makes more sense. But guessing from the text I'd have picked the low byte.
2nd finding, it's a bad idea to set the WDT up at the beginning of the boot process. All kinds of weird behaviour can happen, from reset races that can only be stopped by pulling the power (even a regular hard reset won't do), till lockups, everything seems possible.
I suspect the issue is connected to PLL stability. An early PLL loss of clock highly increases the likelihood (which is actually not difficult to trigger by accident). For some time I experimented with all kinds of workarounds like setting the WDTSUSP bit before performing PLL recovery, but nothing apart from setting the WDT up a little later really helped. I think the problem might, at least in part, be of an electrical nature. The air is very humid tonight, maybe the quartz/PLL simply need a little longer to provide a stable clock.
2nd finding, it's a bad idea to set the WDT up at the beginning of the boot process. All kinds of weird behaviour can happen, from reset races that can only be stopped by pulling the power (even a regular hard reset won't do), till lockups, everything seems possible.
I suspect the issue is connected to PLL stability. An early PLL loss of clock highly increases the likelihood (which is actually not difficult to trigger by accident). For some time I experimented with all kinds of workarounds like setting the WDTSUSP bit before performing PLL recovery, but nothing apart from setting the WDT up a little later really helped. I think the problem might, at least in part, be of an electrical nature. The air is very humid tonight, maybe the quartz/PLL simply need a little longer to provide a stable clock.
Jun 18, 2012
08:09 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 18, 2012
08:09 PM
I agree with you there, I also would have picked the low byte... lasts for 30H count... I would have interpreted that as lasting 48 clock counts duration. Bad wording I guess 😞
Not applicable
Jun 19, 2012
01:41 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 19, 2012
01:41 AM
Yes, but at PCLK/2 that would mean you've only got 48 instruction cycles (as in 96 clock cycles). That's really bad. It takes 64 clock cycles to enter an ISR (1xlcall from the ISR vector, 14xpush, 1xmov). And then the interrupt source has to be detected an the callback funtion entered. So all in all I'd figure it takes about 100 clock cycles to reach an ISR callback routine.
At least the callback doesn't have to push/pop stuff, so it can work from the start.
Everyone recommends not to use callbacks, but nobody has an alternative to offer.
Lugging all the code into a single big ISR is not an option.
| CCLK Cycles| Task | Instruction | Duration
|-----------:|-------------------------------|---------------|-----------
| 0 | Core: Poll interrupt request | | 2
| 2 | Core: Call ISR | lcall | 1 x 4
| 6 | ISR setup: Push registers | 14 x push | 14 x 4
| 62 | ISR setup: Reset PSW | 1 x mov dir,# | 1 x 4
| 66 | ISR: Backup RMAP | … | 3 x 2 + 4
| 76 | ISR: Reset RMAP | … | 2 x 2 + 4
| 84 | ISR: Select callback | |
At least the callback doesn't have to push/pop stuff, so it can work from the start.
Everyone recommends not to use callbacks, but nobody has an alternative to offer.
Lugging all the code into a single big ISR is not an option.
Not applicable
Jun 19, 2012
06:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 19, 2012
06:09 AM
After taking a closer look at the overhead I have decided to spare me the 64 cycles pushing/popping Rn registers for each ISR call and use different register banks for the ISRs. This costs me 16 precious bytes of data memory, I hope it's worth it.
I managed to reduce the backup and reset of RMAP to 8 cycles, but that caused C51 to use one additional byte of memory per ISR (whereas SDCC simple uses a spare register). So I have decided to put my mind elsewhere for now.
| CCLK Cycles| Task | Instruction | Duration
|-----------:|-------------------------------|---------------|-----------
| 0 | Core: Poll interrupt request | | 2
| 2 | Core: Call ISR | lcall | 1 x 4
| 6 | ISR setup: Push registers | 6 x push | 6 x 4
| 30 | ISR setup: Reset PSW | 1 x mov dir,# | 1 x 4
| 34 | ISR: Backup RMAP | … | 3 x 2 + 4
| 44 | ISR: Reset RMAP | … | 2 x 2 + 4
| 52 | ISR: Select callback | |
I managed to reduce the backup and reset of RMAP to 8 cycles, but that caused C51 to use one additional byte of memory per ISR (whereas SDCC simple uses a spare register). So I have decided to put my mind elsewhere for now.
Not applicable
Jun 20, 2012
09:00 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 20, 2012
09:00 AM
WDT still blows up into my face.
If I use the PCLK/2 prescaler and set the WDT up for 5ms I need to spam it with WDTRS ~200 times before I start regular operation (refreshing the WDT once per ms).
And if I write to the flash it resets the µC whatever I do. Even if I set it to wait for 100ms. And my flash writes don't take longer than 2ms.
If I use the PCLK/2 prescaler and set the WDT up for 5ms I need to spam it with WDTRS ~200 times before I start regular operation (refreshing the WDT once per ms).
And if I write to the flash it resets the µC whatever I do. Even if I set it to wait for 100ms. And my flash writes don't take longer than 2ms.