Some random thoughts, some you may know and some you may not: If you have USB enabled, does that mean that the USB stack is interrupt driven? If so, have you set up interrupt priorities and movied timer 1 (by itself) into the high priority interrupt? I think based on your notes you've already done this, but I'd recommed triple checking and making sure that nothing else is configured as a high priority interrupt. If you have to have multiple high priority interrupt routines for some reason, I'd recommend checking the timer interrupt intermixed between the other ISR's. Have you checked for anything turning off interrupts? If there's code you haven't written in your project, it is fairly likely that someone has felt the need to turn off interrupts for certain chunks of code. With the high/low interrupt scheme, you can fix these spots in your code to just turn off low priority interrupts instead of all interrupts. If you have a spare pin, or can repurpose one of your outputs for troubeshooting, just toggle a pin and make sure that you get a nice square wave with the correct period and 50% duty cycle. This will help you isolate the problem between a interrupt firing issue and an ISR issue. I'm assuming you're just letting the timer overflow and using that to generate interrupts, and not messing with the timer values in the ISR to get a specific period of each interrupt. If you're doing the 'adjust the timer in the ISR' thing to get a different period value there are lots of pitfalls there. Some are covered in Section 12.7 in the datasheet. On Mon, Dec 18, 2017 at 11:52 PM, andrew kelley wrote: > I'm having an issue with an occasional (250ms or so) glitch with timer 1 > using interrupts on a 2550 with USB. > > Basically the interrupt increments a counter and creates 4 pulses on one > output and one pulse every twelve on another. > > Only issue is that every so often, either a random pulse is missing or ar= e > closer together than should be. > > I wouldn't think USB would have anything to do with it, as this is the on= ly > interrupt enabled, and a high interrupt at that. > > It's mostly correct, except that glitch, ~250 ms spread. Wdt is disabled. > Communicates the whole time properly over USB, so it's not like the > processor is locking up. No code modifies the counter outside of the > interrupt. > > I'll post the code/LA traces if needed, just wondering if someone has run > in to something similar. > > Thanks, > Andrew > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > --=20 *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 forrestc@imach.com | http://www.packetflux.com --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .