One caveat about modifying the timer to the same value is that the errors due to interrupt latency tend to cause the period of your tick to be longer than expected. The Best strategy is to watch the timer until it ticks, then update the value to your desired value minus the timer reading. That way any latency is accounted for. The other advantage of waiting for a tick (even if you ignore the math) is that you tend to avoid issues related to the timer ticking during an update. If you are just blindly writing to the timer, this might actually be the cause of your issue as your write may be occasionally corrupting the timer values. I don't know enough about the architecture of this particular pic to know if this is likely or not. With all of that said, you may want to consider using the strategy described in 12.5 which allows you to set a CCP up to act as a period register for timer 1. The section says you can't get a timer interrupt this way, but I believe you can get a CCP interrupt which would be at the same period (since the CCP match would likely trigger an interrupt). I don't use this specific part, but I've user a similar approach in other pics. One more note, the section I mentioned previously seems to only be in the later datasheet for this device and only applies in certain circumstances, which may or may not apply. On Dec 19, 2017 7:07 AM, "andrew kelley" wrote: I'll check these suggestions out.. yes I am modifying the timer, but always the same value. I'll read again the section on it. (Err well until I change it, which works). USB is event driven/polled in this application. I'll post up what I find. Thanks, Andrew On Tuesday, December 19, 2017, Forrest Christian (List Account) < lists@packetflux.com> wrote: > 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 note= s > you've already done this, but I'd recommed triple checking and making sur= e > 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 fel= t > 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 squar= e > 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 on= e > > output and one pulse every twelve on another. > > > > Only issue is that every so often, either a random pulse is missing or > are > > closer together than should be. > > > > I wouldn't think USB would have anything to do with it, as this is the > only > > 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 > > > > > > -- > *Forrest Christian* *CEO**, PacketFlux Technologies, Inc.* > Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602 > forrestc@imach.com | http://www.packetflux.com > > > -- > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist > -- 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 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .