WDTCR ATtiny
Quote from yurimoisa on December 14, 2025, 2:04 pmHi
I could not update WDTCR for it has written data 00101111 from the start and not possible to update.
Is it a bug or I do something wrong?
Thanks
Hi
I could not update WDTCR for it has written data 00101111 from the start and not possible to update.
Is it a bug or I do something wrong?
Thanks
Quote from yurimoisa on December 14, 2025, 7:27 pm#include <avr/interrupt.h> #define LED_BIT _BV(PB1) ISR(WDT_vect){ PORTB &= ~LED_BIT; } int main() { DDRB |= LED_BIT; // OUTPUT PORTB |= LED_BIT; cli(); GIMSK |= _BV(PCIE); wdt_reset(); WDTCR |= _BV(WDCE) | _BV(WDE); //enable write WDTCR = _BV(WDTIE) | _BV(WDP2) | _BV(WDP1); //enable interrupt + 128k cycles sei(); while (1) { } }
The app very simple, I expect that in 1 sec the led should off. Bits WDP* always 1 and no interrupt.
Thanks a lot.
#include <avr/interrupt.h>
#define LED_BIT _BV(PB1)
ISR(WDT_vect){
PORTB &= ~LED_BIT;
}
int main()
{
DDRB |= LED_BIT; // OUTPUT
PORTB |= LED_BIT;
cli();
GIMSK |= _BV(PCIE);
wdt_reset();
WDTCR |= _BV(WDCE) | _BV(WDE); //enable write
WDTCR = _BV(WDTIE) | _BV(WDP2) | _BV(WDP1); //enable interrupt + 128k cycles
sei();
while (1)
{
}
}
The app very simple, I expect that in 1 sec the led should off. Bits WDP* always 1 and no interrupt.
Thanks a lot.
Uploaded files:Quote from arcachofo on December 16, 2025, 10:48 amQuote from yurimoisa on December 15, 2025, 6:41 pmHi
a question, this flag means WDTON fuse?
Yes, it is basically WDTON fuse.
Quote from yurimoisa on December 15, 2025, 6:41 pmHi
a question, this flag means WDTON fuse?
Yes, it is basically WDTON fuse.
Quote from yurimoisa on December 16, 2025, 12:49 pmok, thanks
Have you discovered why it is not possible to change WDP* bits in WDTCR? They are always "1".
ok, thanks
Have you discovered why it is not possible to change WDP* bits in WDTCR? They are always "1".
Quote from arcachofo on December 16, 2025, 12:51 pmQuote from yurimoisa on December 16, 2025, 12:49 pmok, thanks
Have you discovered why it is not possible to change WDP* bits in WDTCR? They are always "1".
Not yet.
By the way: which ATtiny are you using?
Quote from yurimoisa on December 16, 2025, 12:49 pmok, thanks
Have you discovered why it is not possible to change WDP* bits in WDTCR? They are always "1".
Not yet.
By the way: which ATtiny are you using?
Quote from arcachofo on December 16, 2025, 2:03 pmThe problem comes from interrupt bit names WDTIE and WDTIF. The default for most devices is WDIE and WDIF.
You can fix it by editing the file: simulide/data/AVR/tiny13/tiny13_regs.xml
At line 32 add an alias for the bit names like this:bits="WDP0,WDP1,WDP2,WDE,WDCE,WDP3,WDTIE|WDIE,WDTIF|WDIF" />
The problem comes from interrupt bit names WDTIE and WDTIF. The default for most devices is WDIE and WDIF.
You can fix it by editing the file: simulide/data/AVR/tiny13/tiny13_regs.xml
At line 32 add an alias for the bit names like this:
bits="WDP0,WDP1,WDP2,WDE,WDCE,WDP3,WDTIE|WDIE,WDTIF|WDIF" />
Quote from yurimoisa on December 16, 2025, 9:49 pmHi
thanks again, now WDT works well.
The only thing is that the bits WDP are always 1 in the monitor though in fact the watch dog cycle is correct exacly as it was set in the program.
Hi
thanks again, now WDT works well.
The only thing is that the bits WDP are always 1 in the monitor though in fact the watch dog cycle is correct exacly as it was set in the program.
Quote from arcachofo on December 16, 2025, 10:27 pmQuote from yurimoisa on December 16, 2025, 9:49 pmThe only thing is that the bits WDP are always 1 in the monitor though in fact the watch dog cycle is correct exacly as it was set in the program.
Thank you, I will solve that issue.
Quote from yurimoisa on December 16, 2025, 9:49 pmThe only thing is that the bits WDP are always 1 in the monitor though in fact the watch dog cycle is correct exacly as it was set in the program.
Thank you, I will solve that issue.
