#avr Logs

Jul 14 2022

05:39 AM specing_ is now known as specing
07:53 AM exp: so to continue the single stepping from yesterday, it certainly clocks the processor for more than one cycle
07:53 AM exp: uh, the peripheral*
07:53 AM exp: stupid words
07:53 AM exp: anyway i don't have any problems with it now, just thought it was notable that peripheral clocks can pose problems
11:58 AM Cracki: so... you'd have to trace the whole thing because it refuses to be controlled precisely
11:59 AM Cracki: are you hand-cranking the master clock, or does "single-stepping" mean running individual instructions, or individual high-level language lines?
01:00 PM exp: Cracki: running on internal pll, single-stepping only in individual instructions is problematic
01:00 PM exp: but single stepping C lines can still show symptoms
01:00 PM exp: ultimately all features now work, so i'm happy
01:01 PM exp: but not knowing this could happen really makes bisecting a problem trickier!
02:19 PM polprog is now known as p
02:19 PM p is now known as polprog
03:17 PM nohit: are you sure its not because your optimazation settings ?
03:32 PM exp: nohit: the behaviour differs depending on if you step in the C view or the dissasembly view, so i don't think it is?
03:32 PM nohit: yeah, just an idea
03:33 PM exp: digikey just put back another of my Ti orders 3 more months
03:33 PM exp: to 12 months
03:33 PM exp: shit's still so fucked
03:34 PM nohit: you do have -O0 ?
03:39 PM exp: nohit: no -Og i think
03:40 PM nohit: yeah i think they are the same
03:40 PM exp: most likely in this case is that stepping the debugger uses the nvm peripheral
03:40 PM exp: so it has to run the peripheral clock with the cpu itself paused
03:41 PM nohit: mkay
03:41 PM exp: it re-reads the contents of the flash to display it i think, so it makes sense
04:51 PM nuxil_ is now known as nuxil
05:39 PM specing_ is now known as specing
10:07 PM qu1j0t3: hi. i am having some bad luck with my duemilanove board. i found a 168 (new chip) somehow had some bad pins -- one pin in port D was weak, and i can't get port C to output at all. i swapped for a 328... burned one of mcudude's optiboot versions for 328 using a polulu isp. (seemed to work fine and it runs blink led now). HOWEVER. avrdude has stopped being able to program the arduino board (the awful
10:07 PM qu1j0t3: stk500_recv timeouts and such). I've set the board rate corresponding to the optiboot version... and i don't understand what could be the issue here. it was programming perfectly with the 168, totally same setup.
10:09 PM qu1j0t3: only change is device 168->328, baud rate setting.
10:10 PM qu1j0t3: OK... decided to change br to 19200. and it worked.
10:10 PM qu1j0t3: funny -- the optiboot i grabbed was for 38400...
10:11 PM qu1j0t3: you've been great listeners.
10:11 PM qu1j0t3: would walltext again.
10:20 PM qu1j0t3: all my delays are wack though. about 20µs for a _delay_us(1)
10:20 PM qu1j0t3: :(
10:25 PM * qu1j0t3 eats ice cream and contemplates life choices
10:39 PM qu1j0t3: one would think i just picked the wrong bootloader, but i picked the one for 16000000 hz
10:39 PM qu1j0t3: will study this further...
10:39 PM qu1j0t3: if it's running at 1mhz for some reason then i would expect delays to be like this
11:43 PM nuxil: i had the same issue using the wrong baudrate when using the arduino as a programmer. when i also set it to 19200 everything worked fine.
11:52 PM nuxil: as far as your delays. are you sure the fuse bits are set correctly and not using the internal RC osc ?
11:53 PM nuxil: or something like that