#avr Logs

Mar 26 2022

01:28 PM LeoNerd: I've got a reeeeeally weird bug on an ATtiny814, and I'm trying not to blame the compiler but I'm running out of ideas
01:37 PM LeoNerd: I'm using the PIT as a scheduler, to run tasks after certain delays. If I just comment-out the code that enables it, the chip doesn't crash at all, but of course the scheduled tasks don't work so nothing much runs
01:37 PM LeoNerd: If I comment out most of the contents of the PIT ISR and enable it again, then it still doesn't crash, but again doesn't run anything
01:37 PM LeoNerd: If I let the body of the ISR be the full code it should be, then the first time the interrupt runs (i.e. almost immediately) the entire chip crashes and reboots... gets stuck in a reboot cycle
01:37 PM cehteh: what interrupt reboots the chip, did you add some diagnostics?
01:39 PM cehteh: make a most minimal example that still shows that bug but commment all working functionality out
01:39 PM LeoNerd: And again, if I comment out the code that enables the PIT, it doesn't crash like that
01:40 PM cehteh: possibly your PIT enabling sequence is borked? is there some stale stuff somewhere around did you clear the interrupt flag manually before enabling the interrupt (other AVR's need to write a 1 to the flag regiuster to clear ist, dunno this)
01:41 PM cehteh: enabling interrupts in the wrong order can sometimes lead to such problems
01:41 PM cehteh: accidentally nesting interrupt, overflowing the stack etc
01:42 PM LeoNerd: Imean it's *possible* but all of that kind of thing is shared code from lots of projects that are all super-stable
01:42 PM cehteh: add diagnostics to toggle a pin, scope it and count how many times it toggles and compare with what you expect
01:42 PM LeoNerd: There's a tiny chance this is a fucked chip. I could try another one
01:43 PM cehteh: well i had this super weird bug once too where some state survived reset and flashing and unless hard pwoer cycle it would crash again
01:44 PM cehteh: possibly some bug in avr-libc forgettting to initialize something, i never figured it out
01:45 PM LeoNerd: https://paste.debian.net/1235694/ -- there, and how it runs
01:49 PM LeoNerd: 0x20 is UPDI reset. 0x00 is.. hrm.. nothing. I'm not sure what that one means
01:49 PM LeoNerd: It's not UPDI, software, watchdog, external, brownout or poweron reset
01:52 PM cehteh: is that avrhal your stuff?
01:52 PM cehteh: i dont know these new chips
01:53 PM LeoNerd: Yeah.. just tidies up some fiddly setting up of USART or whatever
01:53 PM LeoNerd: I've expanded out the PIT one here
01:54 PM LeoNerd: Ah.. I don't check for the PIT being busy before I fiddle with it. Maybe that accounts for a difference.. while it's booting the second time it's still busy from the first so doesn't apply. I'll try adjusting that
01:55 PM LeoNerd: Hrm nope. Identical behaviour
01:55 PM cehteh: disable as much (twi/usart) as possible and use only toggling an gpio for diagnostics
01:55 PM LeoNerd: There's no TWI here. Oh, I've left the .h in place. I should remove it
01:56 PM LeoNerd: Ah, but identical object file so it wasn't being used
01:56 PM cehteh: RTC.CTRLA = RTC_PRESCALER_DIV32_gc;
01:57 PM cehteh: doesnt that start the clock? clocks on other AVR's are started by setting the prescaler
01:57 PM LeoNerd: Yeah that doesn't seem to be relevant.. I'm not using the RTC itself
01:57 PM cehteh: thus this should be last
01:57 PM LeoNerd: Removing that no difference
01:58 PM LeoNerd: I may just try another chip later.. this is starting to feel weird
01:58 PM cehteh: well i dint get the problem correctly, your while(RTC.STATUS) should loop forever?
01:58 PM LeoNerd: It waits until STATUS == 0
02:00 PM cehteh: what toggle that? buildin RTC?
02:00 PM LeoNerd: I'll poke it later. I should be off for dinner now.
02:00 PM cehteh: have fun
02:02 PM cehteh: haha last idea: watchdog enabled for strange reasons?
02:10 PM qu1j0t3: "It's always in the last idea you look"
04:59 PM specing_ is now known as specing
06:36 PM SamantazFox_ is now known as SamantazFox