Back
[01:18:50] <rue_house> http://www.aliexpress.com/item/2PCS-1PCS-CP2102-Module-1PCS-Pro-Mini-Module-Atmega328-5V-16M-For-Arduino-Compatible-With-Nano/1242584516.html
[01:19:00] <rue_house> uh, I think thats cheaper than the ttl usb adapters are
[01:19:30] <rue_house> oh no, I see
[01:19:34] <rue_house> its not 2 ea
[02:23:36] <jerkey> amazing how cheap stuff is!!! if only i could think of something to do with it all!
[03:30:19] <bighead123> Hello
[03:31:18] <bighead123> Does AVR32 audio IC contains hardware MP3 decoder or it is loaded by software?
[03:33:05] <OndraSter_> datasheet does not say?
[03:33:27] <OndraSter_> I don't remember there being any mp3 hardware decoder in it though
[03:42:49] <megal0maniac_afk> rue_house: How about this?
http://www.ebay.com/itm/140972980117
[03:43:18] <megal0maniac_afk> Add LUFA and you've got yourself USB-TTL and a fully featured programmer for all 8bit AVRs
[06:00:06] * The_Coolest probes for signs of life
[06:07:43] <twnqx> no life here.
[06:08:41] <twnqx> braincracker: get a cheap bunch of LEDs with controllers and drive them with a tiny?
[06:09:59] <braincracker> twnqx cant do that leds are given and 1W
[06:10:06] <twnqx> hm
[06:10:21] <The_Coolest> I think I figured out an answer to my question
[06:10:28] <braincracker> but only 8 now, so sw pwm will do
[06:10:32] <The_Coolest> "I'm trying to figure out which address in the eeprom to use to save a flag for the bootloader to activate"
[06:10:46] <The_Coolest> so I'll just use the last byte.
[09:07:26] <rue_house> The_Coolest, so your gonna wear out he last byte first?
[09:07:28] <rue_house> :)
[09:08:55] <The_Coolest> rue_bed lol. I'm more into the last byte is the last one to be used up by the code :P
[09:09:18] <The_Coolest> rue_house this is just a mod to the usbasp loader I'm making for myself
[09:15:21] <rue_house> eeprom or flash?
[09:17:03] <The_Coolest> eeprom
[09:17:17] <rue_house> then its NOT occupied by code :)
[09:17:26] <rue_house> unless its my BF interpreter
[09:17:47] <The_Coolest> yeah, but it's possible that the eeprom will be used up
[09:18:02] <rue_house> ah
[10:05:48] <beaky> hello
[10:07:58] <braincracker> [220951] <beaky> how do i wake up from deep sleep - take the red pill :)
[10:07:59] <braincracker> :)
[10:08:55] <beaky> its amazing how avr is much smaller than a pill
[10:09:04] <beaky> how do people make things that tiny that can do so much?
[10:09:22] <braincracker> haha yeah, wondering if your pills have an avr yet ? ;)
[10:09:47] <braincracker> people don't make vrs, people make machines that make avrs
[10:09:55] <beaky> ah
[10:10:00] <beaky> but those machines run on avr
[10:10:09] <beaky> so thers a chicken egg poblem
[10:10:16] <braincracker> no...
[10:10:21] <braincracker> they can run off relays
[10:10:27] <beaky> whats a relay
[10:10:29] <braincracker> even switches
[10:10:54] <braincracker> relay is a hundred year old switching technology, still used
[10:11:10] <braincracker> electromagnet, relay contact
[10:13:52] <bsdfox> hah yeah the applied sciences machines don't run on avr
[10:14:56] <beaky> i thought the world ran on avr
[10:15:07] <braincracker> beaky
http://web.cecs.pdx.e
[10:15:08] <braincracker> :)
[10:15:39] <beaky> http://web.cecs.pdx.edu/
[10:15:44] <beaky> blank page
[10:16:26] <braincracker> http://web.cecs.pdx.edu/~harry/Relay/index-Pages/Image12.html ^^
[10:16:47] <braincracker> http://web.cecs.pdx.edu/~harry/Relay/
[10:16:49] <braincracker> this works
[10:17:25] <beaky> i love relays they relay information for the good of humanity
[10:20:02] <braincracker> somebody got bored :)
http://hackaday.com/2012/01/16/the-tim-8-is-the-smallest-8-bit-relay-computer-ever/
[10:26:28] <beaky> what is the most interesting avr project
[10:26:32] <beaky> you have done or seen
[10:26:41] <braincracker> led blinker ;<
[10:28:01] <beaky> in one way or another, all avr projects are glorified led blinkers
[10:28:02] <braincracker> clectronic dildo
[10:28:12] <braincracker> e
[10:33:57] <N2TOH> LED blinker eh? have a go with AVE-GCC using the K&R switches and compile AT&T system 5
[10:34:10] <N2TOH> AVR-GCC
[12:43:31] <ThiefMaster> in __vector_default, is there any good way to find out which interrupt fired?
[13:07:54] <N1njaneer> You'd need to check all of the interrupt bits for everything to find that out.
[13:08:20] <N1njaneer> Easier to just hook the interrupts where they are supposed to be at their place in the vector table.
[13:23:30] <ThiefMaster> well, *some* interrupt triggers and nothing works after that until i reset the controller. but i have no idea which one
[13:25:26] <N1njaneer> You specifically have to set the interrupt enable bits for each thing that could cause an interrupt to occur, so that alone should narrow things down. Check the datasheet to see what interrupts are in the table, then (if necessary) look at the breakdown of the assembled output and see which ISR entries have been installed.
[13:25:46] <N1njaneer> You may either be enabling an interrupt bit accidentally, or using the incorrect name for the ISR vector.
[13:27:02] <N1njaneer> WORST CASE you could simply stub in every single ISR vector name and put a unique identification in each to figure out which it is firing in to. If you are debugging via JTAG, a simple while(1); in each would let you get in to the halt condition, then break to see which ISR you are inside of, then work backwards.
[13:27:46] <N1njaneer> Does that make sense?
[13:34:04] <ThiefMaster> yes.. i don't have JTAG available and the only interrupt I enabled is TIMER0_COMPA - but that one has its own ISR
[13:36:31] <ThiefMaster> hm ok looks like something is seriously wrong... one of the LEDs connected to the avr just turned on even though the line where i'm configuring the pin as an output is commented out
[13:37:27] <N1njaneer> Even if the pins are set as inputs, you can have enough leakage that LEDs will faintly light.
[13:37:53] <N1njaneer> Just to confirm that you are vectoring off, I would try turning off global interrupts to confirm that you aren't sticking somewhere else.
[13:38:09] <ThiefMaster> with global interrupts disabled it doesn't happen - already tried that
[13:38:26] <N1njaneer> Are you ONLY enabling TIMER0 for interrupts?
[13:38:35] <N1njaneer> Is your code short enough that you can pastebin it?
[13:39:34] <ThiefMaster> yes. but i'll try a second test program where there isn't much commented-out stuff inbetween
[13:39:46] <ThiefMaster> i'll pastebin that one after testing it
[13:40:33] <gidna> Hi
[13:43:28] <gidna> What is the best AVR to start with?
[13:43:45] <OndraSter_> any
[13:43:49] <bss36504> The core is basically the same, so any
[13:44:10] <bss36504> I like the 328. Decent amount of pins and memory, easy package.
[13:44:40] <gidna> I'd like something cheap to start out, I could damage it
[13:45:37] <bss36504> 328
[13:45:45] <bss36504> still, I think it's pretty great
[13:46:19] <bss36504> http://www.mouser.com/ProductDetail/Atmel/ATMEGA328P-PN/?qs=sGAEpiMZZMuRdXZgphLdVp6CTgYjYYeP
[13:46:26] <ThiefMaster> N1njaneer:
https://gist.github.com/ThiefMaster/adb9a3a23c6e16517668
[13:46:29] <bss36504> $3.31
[13:46:40] <ThiefMaster> it also *only* happens if i keep the crap() call - and only if that function is not in the same source file
[13:47:38] <ThiefMaster> the problem occurs when i send enough data to the uart (just keeping some key pressed in the terminal connected to it does the job)
[13:48:41] <ThiefMaster> the interrupt also doesn't trigger every time. sometimes the avr just resets (or at least restarts the program)
[13:49:17] <ThiefMaster> https://gist.github.com/ThiefMaster/adb9a3a23c6e16517668/#comment-963591 i've added a sample session from the terminal (the 'a' characters are sent by me, anything else is from the avr)
[13:49:23] <devilsadvocate> ThiefMaster: that sounds like your interrupts are overflowing quite spectacularly
[13:49:47] <devilsadvocate> possibly in the 'run out of memory' kind of way
[13:51:33] <gidna> can you advise me also a programmer taht works with avr-gcc
[13:52:10] <ThiefMaster> what could be causing it? the program is rather simple, i don't see anything likely to use a lot of memory
[13:52:17] <OndraSter_> any - gcc has nothing to do with it
[13:54:28] <bss36504> gidna: I'd suggest shelling out for the JTAGICE3 programmer+debugger. $99USD. Like OndraSter_ said though, the toolchain has nothing to do with the programmer. avr-gcc just changes your C code into machine instructions for the mcu.
[13:54:30] <devilsadvocate> ThiefMaster: I'm guessing your vector_default is for debugging the problem?
[13:56:49] <ThiefMaster> yes, i initially noticed the problem because code executed that shouldn't ever execute at that time
[13:57:17] <gidna> I meant avrdude
[13:57:18] <devilsadvocate> ThiefMaster: perhaps start by removing interrupts entirely since you aren't using them
[13:57:18] <ThiefMaster> (i have some rotary encoders connected and the code in if(value != 0) executed without my touching the encoders at all just because i was sending data via serial)
[13:57:58] <devilsadvocate> ThiefMaster: essientially, get this bit of code to work by itself and be sure everything else is fine
[13:58:15] <bss36504> gidna: probably an AVRISP mkii would be better
[13:58:19] <bss36504> cheaper too.
[13:58:30] <ThiefMaster> well i'll need interrupts later so i need it to work with interrupts enabled
[13:59:14] <bss36504> I personally use Atmel Studio with a JTAGICE3, rather than all that yucky, low-level command line stuff that comes with using avrdude. Just my preference though. I like IDEs a lot, and AS6 is way ahead of any other vendor IDE.
[14:02:51] <devilsadvocate> ThiefMaster: you also need to find the smallest chunks of code that (i) functions properly (ii) shows strange behaviour and sort of spot the difference
[14:04:21] <N1njaneer> bss: YES, 1000% yes
[14:04:47] <OndraSter_> bss36504, eggxactly
[14:04:54] <bss36504> N1njaneer: I was waiting for you to back me on that lol
[14:04:54] <N1njaneer> AS6 is the only toolchain I've used thus far that doesn't make me want to gouge my eyes out wih a screwdriver in frustration :)
[14:05:02] <OndraSter_> windows users usually prefer AS6 over cmdline because they are used to VS :D
[14:05:04] <N1njaneer> Sorry, phonecalls and stuff here :)
[14:05:05] <bss36504> or stab your expensive LCDs
[14:05:26] <bss36504> OndraSter_: Ironically, I run all my crap on a Mac through XP VMs
[14:05:29] <OndraSter_> haha
[14:05:47] <OndraSter_> I wanted to stab something at school because we were using either pico/vim or netbeans on solaris thin clients...
[14:05:53] <N1njaneer> OndraSter_: It's a lot faster and easier when you start scaling projects significantly, needing to do a lot of code merge, and run interactive debugging.
[14:05:59] <OndraSter_> so either no IDE and no syntax highlight or verrrrry slow IDE
[14:06:02] <OndraSter_> yep
[14:06:13] <N1njaneer> That and AS6 works and works EVERY TIME
[14:06:23] <OndraSter_> I managed to break it few times...
[14:06:35] <N1njaneer> Especially doing this ARM stuff on their SAM devices, it's the first IDE and toolchain that builds and runs every time I click the button.
[14:06:42] <OndraSter_> ;P
[14:06:45] <bss36504> My Controls class is using the Eclipse CodeWarrior with a freescale kinetis board. Talk about stabbing yourself, yeesh.
[14:06:45] <Tom_itx> piece of cake to crash it
[14:07:03] <bss36504> AS6?
[14:07:31] <bss36504> never had a serious problem, and when I have problems, I can usually blame my computer instead.
[14:07:54] <N1njaneer> I suffered Eclipse for many years for AVR, MinGW, and ARM for Digi's NET+OS implementations, and it sucked hard for all of it. Stupid slow builds, sometimes just would NOT build for a random reason, or the JTAG debugger just locks up for no reason and requires power cycling of some or all components. Complete rubbish.
[14:08:17] <bss36504> Eclipse does many, many things, but none very well.
[14:08:27] <bss36504> except java development, and even then I'd rather use netbeans
[14:08:40] <N1njaneer> As soon as AS6 got in working condition I completely ditched Eclipse. And it's still gcc on the back-end, just a MUCH nicer and extremely mature IDE.
[14:08:45] <OndraSter_> who would do java in the first place
[14:08:57] <devilsadvocate> N1njaneer: summon-arm-toolchain did that too, mostly
[14:09:04] <OndraSter_> Mono > JRE (on linux)
[14:09:06] <bss36504> I think java is an excellent language, it just has a place
[14:09:17] <bss36504> C is the master language, but java is super easy.
[14:09:51] <bss36504> Cross platform is nice. graphical UI design in netbeans is nice. Cross platform UIs is really nice.
[14:09:55] <bss36504> Idk, I like java.
[14:11:11] <bss36504> Oh, and lets not forget that if you can think of some low level task, somebody has probably made a Java Lib for it.
[14:15:48] <N1njaneer> bss36504: I'm a reasonable competent guy, but after nearly 2 days of trying to get the gcc-arm toolchain to work and compile something under Eclipse I just completely gave up. Nearly bought one of the commercial solutions, but then we went a different route. Then AS6 came out. And you click like five things and you have a running ARM solution that you upload and BOOM IT JUST WORKS :)
[14:16:08] <N1njaneer> And that is exciting to me, because I have TRIED the other paths, and AS6, while not perfect, pisses me off the least.
[14:17:05] <bss36504> haha I like that. When we put things into terms of what pisses us off the least. I've had no major issues with AS6, so I see no reason to change.
[14:17:05] <N1njaneer> And in fact, aside from some wonkyness specific to the ASF and thin documentation in places, I actually have practically zero qualms with AS6. Which coming from a critical nitpicker like myself is actually saying something :)
[14:18:13] <bss36504> ASF still baffles me. I think it's so close to being helpful, but AFIK, you have to tie your project to a specific board, which seems stupid. Seems to me that if I want to, say, use the ASF SPI drivers, it should figure it out based on the selected processor, not from some board.
[14:18:36] <bss36504> Also, I have no idea how to define one of those boards.
[14:19:21] <N1njaneer> I've provided them a pretty big earful about the ASF which has gone through the chain, and they acknowledged all of the issues I had with it, but they are working on it actively.
[14:19:50] <bss36504> alright, so maybe we're getting closer to something more helpful. for now I'll just suck it up and write my own damn code.
[14:19:55] <Tom_itx> so are the webdesigners of obamacare
[14:20:03] <bss36504> hehe
[14:20:08] <N1njaneer> Mainly it's a lack of documentation. You can start a project clean and then add ASF stuff to it, but there's a critical missing primer that tells you when board-specific-stuff you either need to include or you need to add yourself when bringing up custom hardware.
[14:20:55] <bss36504> Yeah, that's kind of where I'm at. At face value, it looks like it's done. It's just when you actually try to use it that you realize you have no idea what the hell is going on.
[14:21:11] <N1njaneer> I wasted the better part of a week trying to figure out WTF the GMAC could receive ethernet packets fine, but had some link problems and would NOT allow me to SEND packets, but wasn't erroring out. Turned out there was ONE SINGLE #define missing, buried in a file, that set the PHY type for initialization. And without that line it half-worked, but not quite.
[14:21:28] <bss36504> I'd even have no problem defining board parameters for a project, just to use ASF, but they dont tell you how.
[14:21:38] <N1njaneer> Exactly.
[14:22:03] <bss36504> haha nice. Those pesky #defines
[14:22:04] <N1njaneer> Also the ASF doesn't play nice with C++ code without some tweakings, which was part of my other constructive rant to them. Again, they are aware of it.
[14:23:40] <bss36504> Haven't tried to do C++ for embedded, so I havent seen that problem. Then again, C++ is still not my strongest language, so I generally stick to C and java, for embedded and PC respectively.
[14:25:32] <N1njaneer> I use C++ because for larger projects it's a lot easier to manage things and wrap peripherals and processes for reuse, even though you aren't generally doing new/delete operations, etc. Being able to nicely package things (like my network stack) that are completely stand-alone units that can be moved from project to project with minimal dependency is great.
[14:26:27] <bss36504> Oh absolutely. I love the concepts of OOP design, and when I can, I apply some of the methodologies to my C code, but there are certain benefits to even just the compiler checks that C++ gives you for abstracting things.
[14:42:50] <ThiefMaster> devilsadvocate / N1njaneer: this is the smallest program where i could reproduce the problem:
https://gist.github.com/ThiefMaster/adb9a3a23c6e16517668#comment-963618
[14:43:08] <ThiefMaster> i can't remove anything else or i won't be able to trigger the problem anymore
[14:43:40] <ThiefMaster> again, when i remove the crap() call everything works
[14:43:45] <bss36504> Whats the quick verson of what's happening?
[14:44:34] <N1njaneer> bss36504: unexpected interrupts is firing for him on a vector he isn't hooking, trying to figure out which one
[14:44:41] <N1njaneer> (on phone again, brb)
[14:44:47] <ThiefMaster> some interrupt triggers once i receive a few chars on the uart. i have no idea which one but things break (sometimes it also causes my program to restart from the beginning)
[14:45:25] <bss36504> Well thats wacky.
[14:47:18] <bss36504> And you're saying that this program is the only thing being compiled, along with crap.c?
[14:49:46] <ThiefMaster> yes
[14:51:11] <ThiefMaster> https://gist.github.com/ThiefMaster/adb9a3a23c6e16517668#comment-963621 is the disassembly of the compiled program
[14:51:47] <N1njaneer> I don't see aything that is enabling interrupts in that code.
[14:52:30] <N1njaneer> Nor anything turning on global interrupts
[14:52:48] <ThiefMaster> they are enabled by default, aren't they? at least when i tried it the default interrupt function was called
[14:53:05] <N1njaneer> No, you have to specifically enable global interrupts.
[14:53:14] <bss36504> what happens if you throw a cli(); at the beginning of main?
[14:53:18] <bss36504> just to be safe
[14:53:40] <N1njaneer> The only one that kind of runs as a non-maskable interrupt (if you want to call it that) is the reset vector
[14:53:55] <N1njaneer> Which should direct a jump over to the start of main()
[14:54:15] <bss36504> Have you tried a different chip?
[14:54:35] <N1njaneer> Unless you are calling sei() or manipulating the global interrupt register directly, no interrupts will ever occur, even if enabled locally in the peripherals.
[14:54:40] <ThiefMaster> hmm well, with exactly that code the LED connected to PA0 turns on once i send data to the uart
[14:54:51] <N1njaneer> Which chip?
[14:54:55] <bss36504> 644
[14:55:07] <bss36504> (according to the makefile)
[14:55:08] <N1njaneer> Also have you verified that you are setting the target CPU to the correct model?
[14:55:12] <ThiefMaster> yes
[14:55:38] <ThiefMaster> same problem when i call cli(); (odd, i could swear that this avoided the problem earlier)
[14:56:03] <N1njaneer> Yeah, I would possibly try another chip, just to be safe and to eliminate a variable.
[14:56:13] <N1njaneer> Do you have clean power and proper decouplig on all the power pins?
[14:56:19] <bss36504> N1njaneer: Worked for someone yesterday :P
[14:56:27] <devilsadvocate> ThiefMaster: in the previous (slightly larger) code, did you get the BEGIN multiple times?
[14:57:53] <ThiefMaster> yes, when sending stuff. that's why i assumed it sometimes reset or restarted main()
[14:58:55] <ThiefMaster> hmm... could i have damaged the chip? i switched the power supply at some point to a different one while rx/tx were still connected. and i just tested that again for a short moment and the LED connected to in stayed on even though vcc was not connected anymore. so there must have been some current flowing from rx to pa0 (and other pins with leds connected i guess)
[14:59:20] <N1njaneer> Er, you have just "UDR0" in the do/while loop. I'm not sure if that will accomplish what you want it to without doing like a "dummy = UDR0;" operation
[14:59:47] <N1njaneer> Also, keep in mind the receive buffer is only one byte deep on AVR's
[15:00:13] <bss36504> generally not good for the I/Os when you apply power without VCC being supplied
[15:00:49] <N1njaneer> But again I don't see how any interrupts could ever fire without 1> peripheral interrupt enable bits being set 2> without global interrupts enabled
[15:00:57] <N1njaneer> So I'm going to guess the problem is likely elsewhere.
[15:01:30] <bss36504> I agree, seems very weird. Anyway, gotta go for a bit. talk to y'all later
[15:01:32] <ThiefMaster> N1njaneer: i know - but for simple testing it was enough - and later i'll use interrupt-based receiving with a buffer big enough to hold the data i expect
[15:02:01] <N1njaneer> ThiefMaster: Generally the silicon tends to be extremely forgiving (it you're not, like, dumping excessive voltage randomly into a pin) in a scenario like you described. There are clamping diodes that will generally deal with protecting the chip if there isn't excessive current flow.
[15:02:01] <ThiefMaster> anyway, i'll try it with my other chip
[15:02:26] <N1njaneer> (even if the chip is unpowered)
[15:02:48] <N1njaneer> Thief: Other question -- what is your clocking source?
[15:03:00] <N1njaneer> Try setting to run on internal clock and see if you can get it to lock up.
[15:03:12] <ThiefMaster> 18.432 mhz crystal
[15:03:32] <N1njaneer> We had someone months back with similar oddities, and it actually turned out to be bad connections on his crystal and/or missing proper caps on the crystal. The oscillation was literally just stopping and resetting the chip.
[15:03:53] <N1njaneer> Are you running on +5V?
[15:04:35] <ThiefMaster> yes
[15:04:47] <ThiefMaster> 3v3 on rx though
[15:04:56] <ThiefMaster> but that is still within the specs..
[15:05:04] <N1njaneer> For input to the chip that's fine.
[15:05:38] <N1njaneer> I would try scoping your clock crystal to ensure proper clocking, or try switching to internal 8Mhz oscillator and trying to isolate the problem
[15:08:01] <ThiefMaster> ok, same problem with my other chip. so i'll try the internal clock now
[15:17:11] <ThiefMaster> do i need to disconnect the external crystal or will changing the fuse be enough?
[15:17:31] <N1njaneer> Fuse is fine.
[15:17:42] <N1njaneer> Then recalculate your baud rate divisor
[15:18:04] <N1njaneer> Note that you may get some scrabled characters as the internal clock isn't very accurate, but that should suffice for purposes of this particular test.
[15:20:36] <devilsadvocate> ThiefMaster: there are supposed to be some bits somewhere that store the nature of reset. I don't remember now
[15:21:19] <devilsadvocate> ThiefMaster: as soon as you get into main, you could copy out that register and send it over via UART later to see if the cause of the reset is somewhere else. A brownout, perhaps, if you have the BOD enabled
[15:21:59] <ThiefMaster> BOD is disabled
[15:29:12] <devilsadvocate> ThiefMaster: I'm guess you have the watchdog diabled as well, and have the reset pin pulled up?
[15:30:14] <ThiefMaster> oh.. the reset pin is connected directly to my programmer.. i guess it already pulls it up - but i didn't add my own pullup
[15:30:28] <ThiefMaster> and for some weird reason avrdude fails at writing the fuse
[15:30:34] <devilsadvocate> ThiefMaster: try that. and disconnect your programmer when you test
[15:31:20] <devilsadvocate> For good measure I'd suggest checking your power supply as well
[15:32:01] <ThiefMaster> (lock is 0xff, so that's not why i can't write the fuse)
[15:32:30] <N1njaneer> The reset pin doesn't need external pull-up; it has one internally in the chip.
[15:32:43] <devilsadvocate> ThiefMaster: What programmer are you using?
[15:32:58] <devilsadvocate> N1njaneer: it does. I've been bitten by it enough times to know
[15:33:06] <ThiefMaster> http://shop.myavr.de/index.php?404;http://myavr.de:80/shop/article.php?artDataID=36 that one
[15:33:16] <N1njaneer> But yes, ideally throw an o'scope on your VCC pin, and absolutely make sure you have 0.1uf caps on all of your power pins.
[15:33:49] <devilsadvocate> or atleast one nearby (the caps)
[15:34:48] <devilsadvocate> ThiefMaster: are you using this for the USB-UART as well?
[15:35:07] <ThiefMaster> no, i've connected it to my raspberry pi
[15:35:16] <N1njaneer> devilsadvocate: Bitten by it how? I've stopped adding external pull-up on the reset pins to all of my designs because they have proven unnecessary. I have many thousands of devices out in the field without issue.
[15:36:35] <N1njaneer> AVR's have a 30-60K internal pull-up on the reset, so unless you are dragging it out along some long cabling or such I can't see how it would be affected, provided the rest of the hardware design is correct.
[15:37:58] <devilsadvocate> N1njaneer: I've seen noise on the reset pin on occasion. Usually when used with a motor in the vicinity, so it could be a power supply/emi issue. Usually I prefer a 10K or so pullup. If I remember correctly datasheet says 100K internal.
[15:39:35] <N1njaneer> Sounds like bad EMI/inadequate supply decoupling. In those areas, probably not a bad thing to add a bit more. And yes, it's 30-60K on the datasheet. :)
[15:39:45] <N1njaneer> 10K's are cheap :)
[15:40:33] <N1njaneer> And yes, noisy power will cause all host of mysterious symptoms to manifest.
[15:45:39] <ThiefMaster> interesting, with the internal oscillator it works fine
[15:47:25] <N1njaneer> I would check your clock crystal, the caps for the crystal, and the fuse settings you are using to drive it. Also try setting CLK_OPT if it's not set.
[15:48:29] <N1njaneer> I have seen some differences in silicon batches that will drive clock crystals differently and cause them to run at incorrect rates, or even stop when probing with a 10x probe. Setting CLK_OPT has always fixed this, as it causes the clock crystal to be driven harder at the expense of slightly more power consumption.
[15:49:09] <N1njaneer> So we set all chips which have a CLK_OPT fuse now by default unless it's a special-case scenario.
[15:50:26] <ThiefMaster> the 644 doesn't seem to have that fusebit
[15:51:10] <N1njaneer> Yeah, some do some don't
[15:51:30] <N1njaneer> Make sure you are setting your clocking fuses correctly for your type and speed of crystal.
[15:52:52] <ThiefMaster> Ext. Crystal Osc.; Frequency 8.0- MHz; Start-up time: 16K CK + 65 ms; [CKSEL=1111 SUT=11]
[15:52:54] <ThiefMaster> should be fine, no?
[15:53:12] <N1njaneer> Should be, yes.
[15:53:24] <N1njaneer> You have verified the caps you are using match the cystal spec?
[15:53:49] <N1njaneer> And that the crystal is of an appropriate type for the AVR?
[15:54:48] <ThiefMaster> it's a simple quartz crystal.. i bought them together with the avrs a few years ago and i guess i checked that when buying them
[15:54:54] <ThiefMaster> i'll check the caps now..
[16:07:14] <ThiefMaster> just checked, 22pf
[16:14:34] <N1njaneer> They match the crystal?
[16:15:08] <bss36504> Can you set it to external, run the code, but monitor the clock with a scope on the CLKOUT pin?
[16:15:24] <N1njaneer> I normally use 22pf's on my designs that require quartz, so as long as the crystal calls for 20-22pf that should be fine.
[16:15:31] <N1njaneer> bss36504: That's a good idea.
[16:15:39] <N1njaneer> Jsut enable CLKOUT fuse
[16:48:57] <ThiefMaster> intersting, when enabling CKDIV i don't have the problem anymore either
[16:49:26] <bss36504> what voltage are you running at?
[16:49:40] <ThiefMaster> 5v
[16:50:07] <bss36504> darn.
[16:50:08] <N1njaneer> Yeah something really odd is going on there. This shouldn't be happening.
[16:50:14] <ThiefMaster> when measuring on the CLKOUT pin i get this on my scope (no idea if the signal sucks or the scope):
http://i.imgur.com/P3OuEc1.png
[16:50:15] <N1njaneer> bss36504: That was my thought earlier as well
[16:51:14] <bss36504> Looks alright-ish. What do you think N1njaneer?
[16:51:37] <N1njaneer> ThiefMaster: That's a bit odd with the overshoots and in there, but probably acceptable. I would expect a bit more of a squared-off waveform when coming from the AVR. I assume you are using an actual o-scope probe and not just a wire? :)
[16:51:53] <N1njaneer> +and bit of ringing in there
[16:52:00] <ThiefMaster> yeah, it's a proper probe
[16:52:27] <bss36504> this is super weird. Did you try a new chip while I was away by chance?
[16:52:51] <ThiefMaster> yes. actually i'm on the new one right now since i didn't want to change it back after seeing the problem on both chips
[16:56:03] <N1njaneer> I would suggest possibly changing your clock crystal and caps out, too, or at very least probe the pins of the actual crystal. You'll probably need to set the probe to 10x to not interfer with the clock.
[16:56:52] <ThiefMaster> already tried using another crystal (i only have those two that do well for baud rates)
[16:57:04] <ThiefMaster> http://i.imgur.com/UIwa2V6.png - that's the scope output without ckdiv
[16:57:29] <ThiefMaster> (i don't know how good the scope is, might be more inaccurate at very high frequencies)
[16:57:58] <N1njaneer> Yeah there appars to be an overlayed lower frequency on top of the primary there.
[16:58:19] <N1njaneer> It may be the scope aliasing, though. Still a good reason to have an analog scope around at times.
[17:03:50] <ThiefMaster> in the worst case i could try using a software-only uart.. but i'd rather not do that
[17:09:36] <devilsadvocate> ThiefMaster: I can tell you that I use the 644 at 18.532 FCLK and 19200 baud with no problems whatsoever without any quirky sort of behaviour
[17:25:15] <ThiefMaster> looks i'm not the only one with that problem
[17:25:15] <ThiefMaster> http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=66071&start=0
[17:30:03] <N1njaneer> ThiefMaster: I'm honestly really boggled by this one. I haven't run across anything remotely similar that hasn't had the issues resolved by looking at the stuff I had suggested.
[17:30:07] <ThiefMaster> btw, my MCUSR is 0 when those "resets" happen
[17:30:25] <N1njaneer> Is it resetting randomly now, or still vectoring to the bad ISR?
[17:30:44] <ThiefMaster> i removed the ISR since it didn't really help debugging anyway
[17:30:58] <N1njaneer> So now you are just seeing a random reset?
[17:32:28] <N1njaneer> What does the rest of the hardware look like around the chip? Is this on a protoboard, etc?
[17:32:42] <ThiefMaster> yeah, it's on a breadboard
[17:32:55] <ThiefMaster> there are two rotary encoders connected but i tried disconnecting them before
[17:36:07] <N1njaneer> copious use of 0.1uf caps right at the micro's pins?
[17:37:04] <ThiefMaster> between vcc and gnd?
[17:39:58] <ThiefMaster> i have one but it's next to the chip, so not *that* close to the pins
[17:42:29] <N1njaneer> Yeah, you want as many of those as possible.
[17:43:32] <ThiefMaster> that's my current setup:
http://i.imgur.com/scEu5cN.jpg
[17:52:59] <ThiefMaster> found the problem!
[17:53:32] <ThiefMaster> i needed to change the clock fuse to "full-swing crystal oscillator" instead of just "crystal oscillator".
[17:53:34] <N1njaneer> Do tell!!
[17:53:43] <ThiefMaster> (apparently that's what CKOPT does on other avrs)
[17:53:43] <N1njaneer> Oh yes, that's the CLKOPT fuse :)
[17:53:51] <N1njaneer> Yay I was 95% right :)
[17:54:11] <ThiefMaster> also, the datasheet even says that the device is rated only up to 16mhz without full-swing mode
[17:54:21] <ThiefMaster> bleh. one evening wasted on that crap...
[18:02:34] <N1njaneer> Oh well you fixed it!
[18:10:20] <ThiefMaster> http://electronics.stackexchange.com/questions/92711/why-does-my-avr-act-weird-resets-data-corruption-when-receiving-a-few-bytes-o
[18:10:24] <ThiefMaster> hopefully this helps someone else in the future ;)
[18:10:52] <Casper> missing decoupling cap?
[18:11:05] <Casper> or ckopt not set?
[18:13:08] <ThiefMaster> ckopt not set to full-swing was the problem for me (which is why i posted the answer together with the question)
[18:15:57] <Casper> ckopt is a common issue
[18:16:07] <Casper> because, as always, people do not read the datasheet :D
[18:16:42] <Casper> hmmm
[18:16:58] <Casper> look like I'll receive everything that I ordered in china at about the same time...
[18:25:43] <N1njaneer> Casper: I asked about CLKOPT being set several hours ago, actually :)
[18:25:59] <N1njaneer> It's just not shown as a discreet fuse with the programmer he's using :)
