[PIC]: 18f2550 timer 1 interrupt glitch?

[andrew kelley]

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 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

[Nicola Perotto]

Hi Andrew,

On 19/12/2017 07:52, 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.
>
> ...
>
> I'll post the code/LA traces if needed, just wondering if someone has run
> in to something similar.
I had a similar issue: a bug! A small mistake in a calculation left out a carry.
I found when got the exact period of the glitch: it was very precise!
    Nicola

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman

[Forrest Christian (List Account)]

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 <***@gmail.com>
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 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: [phone] | Address: 3577 Countryside Road, Helena, MT 59602
***@imach.com | http://www.packetflux.com
<http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux>
<http://twitter.com/@packetflux>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

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) <
***@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 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 <***@gmail.com>
> 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
> 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: [phone] | Address: 3577 Countryside Road, Helena, MT 59602
> ***@imach.com | http://www.packetflux.com
> <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux>
> <http://twitter.com/@packetflux>
> --
> 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

[Forrest Christian (List Account)]

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" <***@gmail.com> 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) <
***@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 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 <***@gmail.com>
> 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
> 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: [phone] | Address: 3577 Countryside Road, Helena, MT 59602
> ***@imach.com | http://www.packetflux.com
> <http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux>
> <http://twitter.com/@packetflux>
> --
> 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
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Brent Brown]

On 19 Dec 2017 at 8:57, 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.

You're probably on to this already, and we haven't seen your code, but stopping the
timer before writing to it will be important.

Timer incrementing or decrementing in the midst of instructions accessing it messes
things up, with the kind of irregularities you're seeing. Especially a problem with a
16 bit timer and 8 bit instruction width.

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

Ok so I took another look at it..

Timer 1 is the only interrupt in use.
In the interrupt, I increment a variable, which I check to generate a
signal (4 pulses @ a particular interval, and toggle another pin every 12
pulses).

All that seems to work, except that the variable is seeming to skip counts
occasionally. I'm not so concerned about jitter at this point.

I went so far as turning the timer off, resetting the int flag, writing the
counter with my count setting, and clearing the flag again before turning
the timer back on at the end of the interrupt. I'm baffled.

It should not skip a count on the variable in any case, especially with the
timer being off to write it. No rmw port issues, I'm writing to latb to
toggle pins.

I'll see about getting my laptop on the internet to post a code section of
the interrupt. I've checked the errata and the data sheet.. nothing
relevant. It also does it if I use a different timer. Simulates fine
however but that's not actual hardware.

Befuzzled,
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

[andrew kelley]

Regarding the 8 bit write to a 16 bit timer, the write is buffered
according to the datasheet until the low byte is written. (Not inc/Dec,
whole write) timer interval is longer than the interrupt.

On Tuesday, December 19, 2017, Brent Brown <***@eds.co.nz> wrote:

> You're probably on to this already, and we haven't seen your code, but
> stopping the
> timer before writing to it will be important.
>
> Timer incrementing or decrementing in the midst of instructions accessing
> it messes
> things up, with the kind of irregularities you're seeing. Especially a
> problem with a
> 16 bit timer and 8 bit instruction.
>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

Mcc18 code. Interrupt happens, just unsure why it skips degCtr
occasionally. There are never 5 pulses. Only ever 3 or 4. Different pulses
will be missing. Unstable interval between failures. Cmp never fails to
miss a toggle however. It's a crankshaft/camshaft sensor simulator. Both
pwm modules are in use for a poor man's "DAC" but they use other timers.
Code has the same issue without USB code and with a different timer.


void HighPriorityISRCode()
{
//A3 silicon errata
_asm pop _endasm

if(PIR1bits.TMR1IF)
{
T1CONbits.TMR1ON=0;
WriteTimer1(degTmrCt);
PIR1bits.TMR1IF=0;
degCtr++;
degTDC++;
PIR1bits.TMR1IF=0;
switch(degCtr)
{
case(28):
case(48):
case(68):
case(88):
LATB &= CKP_ON;
break;
case(30):
case(50):
case(70):
case(90):
LATB |= CKP_OFF;
break;
case(120):
degCtr=0;
cmpCtr--;
if(cmpCtr==0)
{
LATB ^= CMP_SIG;
cmpCtr=3;
}
break;
}
if(degTDC==60)
degTDC=-60;
T1CONbits.TMR1ON=1;
}
}
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

>
> Ok so I massively simplified the code to instead output the low two bits
> of the counter variable and let it just run (while still reloading the
> timer interval with the timer off for the duration of the interrupt). It
> still hiccups (verified with a logic analyzer). the timer interval did not
> affect the hiccup, but seems like it coincides with n number of timer
> interrupts.. the interrupt routine is now very short, so it shouldn't be
> missing any interrupts for sure. I'm not sure what more to do to figure it
> out, except maybe put the whole counter out and log the whole byte.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

> Ok so I massively simplified the code to instead output the low two bits
>> of the counter variable and let it just run (while still reloading the
>> timer interval with the timer off for the duration of the interrupt). It
>> still hiccups (verified with a logic analyzer). ...
>
>
> Appears as though it's every +/-8 ms, regardless of timer interval... Any
> significance there? I am running the timer at 1:1 prescale. 48mhz. Usb
> enabled and running but polling not interrupt. Wdt disabled (would be
> disconnecting from PC if it was resetting?)
>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[smplx]

On Wed, 20 Dec 2017, andrew kelley wrote:

>> Ok so I massively simplified the code to instead output the low two bits
>>> of the counter variable and let it just run (while still reloading the
>>> timer interval with the timer off for the duration of the interrupt). It
>>> still hiccups (verified with a logic analyzer). ...
>>
>>
>> Appears as though it's every +/-8 ms, regardless of timer interval... Any
>> significance there? I am running the timer at 1:1 prescale. 48mhz. Usb
>> enabled and running but polling not interrupt. Wdt disabled (would be
>> disconnecting from PC if it was resetting?)
>>

the problem might actually be outside the ISR. Try moving the variables to
different possitions in RAM and see if that affects the jitter. Try
putting other variables around them (make sure they are referenced and
don't get optimised out). Try disabling all compiler optimisation.

Regards
Sergio Masci
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[mike brown]

I'm pretty rusty at my pic skills these days, but this smells like a bank
switching issue. Somewhere there might be an assumption on what bank is
selected. This assumes that the 18f2550 is anything at all like the 16f
series.

On Dec 20, 2017 06:16, "smplx" <***@allotrope.net> wrote:

>
>
> On Wed, 20 Dec 2017, andrew kelley wrote:
>
> >> Ok so I massively simplified the code to instead output the low two bits
> >>> of the counter variable and let it just run (while still reloading the
> >>> timer interval with the timer off for the duration of the interrupt).
> It
> >>> still hiccups (verified with a logic analyzer). ...
> >>
> >>
> >> Appears as though it's every +/-8 ms, regardless of timer interval...
> Any
> >> significance there? I am running the timer at 1:1 prescale. 48mhz. Usb
> >> enabled and running but polling not interrupt. Wdt disabled (would be
> >> disconnecting from PC if it was resetting?)
> >>
>
> the problem might actually be outside the ISR. Try moving the variables to
> different possitions in RAM and see if that affects the jitter. Try
> putting other variables around them (make sure they are referenced and
> don't get optimised out). Try disabling all compiler optimisation.
>
> Regards
> Sergio Masci
> --
> 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

[a***@stfc.ac.uk]

Certainly sounds like a memory corruption issue, with bank switching being a likely culprit.

Is the original code written in assembler or C, I thought I saw MCC18 mentioned, but that may be another thread I'm thinking of.


>
> I'm pretty rusty at my pic skills these days, but this smells like a bank
> switching issue. Somewhere there might be an assumption on what bank is
> selected. This assumes that the 18f2550 is anything at all like the 16f series.
>
> On Dec 20, 2017 06:16, "smplx" <***@allotrope.net> wrote:
>
> >
> >
> > On Wed, 20 Dec 2017, andrew kelley wrote:
> >
> > >> Ok so I massively simplified the code to instead output the low two
> > >> bits
> > >>> of the counter variable and let it just run (while still reloading
> > >>> the timer interval with the timer off for the duration of the interrupt).
> > It
> > >>> still hiccups (verified with a logic analyzer). ...
> > >>
> > >>
> > >> Appears as though it's every +/-8 ms, regardless of timer interval...
> > Any
> > >> significance there? I am running the timer at 1:1 prescale. 48mhz.
> > >> Usb enabled and running but polling not interrupt. Wdt disabled
> > >> (would be disconnecting from PC if it was resetting?)
> > >>
> >
> > the problem might actually be outside the ISR. Try moving the
> > variables to different possitions in RAM and see if that affects the
> > jitter. Try putting other variables around them (make sure they are
> > referenced and don't get optimised out). Try disabling all compiler
> optimisation.
> >
> > Regards
> > Sergio Masci
> > --
> > 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

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

I further simplified it to a non USB, non interrupt main loop with blocking
delay and outputting a incremented variable to latb and it still
glitches... Perhaps this chip is damaged. I'll swap it out with another and
try again. Decoupling caps are on the power supply and the chip.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Scott]

Some blind shots in the dark:
Are your ISR variables accessed outside the ISR (i.e. in your main loop)?
Have you declared them volatile?
Are they 8 bit or 16? Handling rolling over correctly?



On Wed, Dec 20, 2017 at 10:42 AM, andrew kelley <***@gmail.com>
wrote:

> I further simplified it to a non USB, non interrupt main loop with blocking
> delay and outputting a incremented variable to latb and it still
> glitches... Perhaps this chip is damaged. I'll swap it out with another and
> try again. Decoupling caps are on the power supply and the chip.
> --
> 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

[andrew kelley]

8 bit, volatile, only time it is written is when the serial link updates
the timer reset variable. Also was able to duplicate it when not using
interrupt or the timer.

On Wednesday, December 20, 2017, Scott <***@gmail.com> wrote:

> Some blind shots in the dark:
> Are your ISR variables accessed outside the ISR (i.e. in your main loop)?
> Have you declared them volatile?
> Are they 8 bit or 16? Handling rolling over correctly?
>
>
>
> On Wed, Dec 20, 2017 at 10:42 AM, andrew kelley <***@gmail.com>
> wrote:
>
> > I further simplified it to a non USB, non interrupt main loop with
> blocking
> > delay and outputting a incremented variable to latb and it still
> > glitches... Perhaps this chip is damaged. I'll swap it out with another
> and
> > try again. Decoupling caps are on the power supply and the chip.
> > --
> > 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
>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[smplx]

On Wed, 20 Dec 2017, mike brown wrote:

> I'm pretty rusty at my pic skills these days, but this smells like a bank
> switching issue. Somewhere there might be an assumption on what bank is
> selected. This assumes that the 18f2550 is anything at all like the 16f
> series.

so moving the variable and/or adding other variables around it and/or
disabling all optimisations ***WILL*** cause the symptoms to change...

Yep, thought of that... so let's see if we can affect the symptoms then we
can play with these to identify the cause (just gorra stop watching house
:-))

Regards
Sergio Masci

>
> On Dec 20, 2017 06:16, "smplx" <***@allotrope.net> wrote:
>
>>
>>
>> On Wed, 20 Dec 2017, andrew kelley wrote:
>>
>>>> Ok so I massively simplified the code to instead output the low two bits
>>>>> of the counter variable and let it just run (while still reloading the
>>>>> timer interval with the timer off for the duration of the interrupt).
>> It
>>>>> still hiccups (verified with a logic analyzer). ...
>>>>
>>>>
>>>> Appears as though it's every +/-8 ms, regardless of timer interval...
>> Any
>>>> significance there? I am running the timer at 1:1 prescale. 48mhz. Usb
>>>> enabled and running but polling not interrupt. Wdt disabled (would be
>>>> disconnecting from PC if it was resetting?)
>>>>
>>
>> the problem might actually be outside the ISR. Try moving the variables to
>> different possitions in RAM and see if that affects the jitter. Try
>> putting other variables around them (make sure they are referenced and
>> don't get optimised out). Try disabling all compiler optimisation.
>>
>> Regards
>> Sergio Masci
>> --
>> 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
>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

Problem isolated. Programmed another device set up with the same code and
problem is gone. Now, to figure out Exactly what is faulty on the other
board... I'll post what it is when I find out.. but for now it's isolated
at least. Haven't tried the interrupt code on the other hardware, but I'm
suspecting it's fine, given that the first board was screwing up just a
timer loop with output of a incremented variable without interrupts.

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

[andrew kelley]

Well, I have tried the following to no avail:

swapped the chip out for another one (18f2550, other target that
worked was a 18f4550)
swapped the crystal out (20mhz, tried adding caps to ground like DS
recommends, no change)
swapped out bypass capacitors
swapped out Vusb capacitor

with no changes in behavior. I'd hate to have to retarget to a 18f4550
but I don't see what is wrong. It is not a complex circuit.. basically
just the USB connection (powered from USB), USB cap, decoupling caps,
a few resistors (not connected to anything right now), and a couple
NPN drivers (also not connected right now). The circuit is built on
vector board and a .6" chip won't quite fit nearly as well, due to the
other stuff already on the board (mostly LEDs and resistors, intent is
to simulate a engine and capture the injector & coil pulse width to
aid in testing the PCM while developing code instead of risking an
engine).. I could put the PIC on a separate board because it only has
8 lines tied to the ECU.. Probably not a bad idea anyway to help
isolate the PCM from the PIC. Still it bothers me as to why the code
runs fine on a 18f4550, but not a 18f2550. Not the target code mind
you, but the simplest test code that reproduces the issue.

<CODE>
char degCtr;
void main(void)
{
char tmp;
TRISB=0;
degCtr=0;
while(1)
{
tmp=255;
while(tmp) tmp--;
tmp=255;
while(tmp) tmp--;
degCtr++;
LATB=degCtr;
}
}
</CODE>

On the 2550, that code glitches every ~7-8ms. I can change the values
tmp is reloaded with and it does not change the glitch interval. Two
different 2550's exhibit the same behavior (the third one I have would
not program CONFIG bits properly, so I couldn't use it). However, 4550
runs the same code, as expected, with PB7-PB0 cascading frequency
outputs. The 2550 exhibits weird behavior, as though the degCtr is
being reset or modified arbitrarily. There doesn't seem to be a
pattern to the glitch other than the timing. WDT, BOR, STOVF, MCLR are
disabled on both working and non working targets. I suppose it is
possible that both 2550's are faulty but no real way to qualify that
unless I order a few more.

Yes I know the code is not optimally written.

Appreciate all your collective patience with my debugging,
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

[Anthony Nixon]

Maybe a dumb thing but have you tried PORTB=degCtr

I am using a 18F47K40 and in some code segments if I write to LATx
registers the code failed, but writing to PORTx and it works.

Maybe I am reading the data sheet incorrectly.

cheers

Tony

On Thu, Dec 21, 2017 at 5:14 PM, andrew kelley <***@gmail.com> wrote:
> Well, I have tried the following to no avail:
>
> swapped the chip out for another one (18f2550, other target that
> worked was a 18f4550)
> swapped the crystal out (20mhz, tried adding caps to ground like DS
> recommends, no change)
> swapped out bypass capacitors
> swapped out Vusb capacitor
>
> with no changes in behavior. I'd hate to have to retarget to a 18f4550
> but I don't see what is wrong. It is not a complex circuit.. basically
> just the USB connection (powered from USB), USB cap, decoupling caps,
> a few resistors (not connected to anything right now), and a couple
> NPN drivers (also not connected right now). The circuit is built on
> vector board and a .6" chip won't quite fit nearly as well, due to the
> other stuff already on the board (mostly LEDs and resistors, intent is
> to simulate a engine and capture the injector & coil pulse width to
> aid in testing the PCM while developing code instead of risking an
> engine).. I could put the PIC on a separate board because it only has
> 8 lines tied to the ECU.. Probably not a bad idea anyway to help
> isolate the PCM from the PIC. Still it bothers me as to why the code
> runs fine on a 18f4550, but not a 18f2550. Not the target code mind
> you, but the simplest test code that reproduces the issue.
>
> <CODE>
> char degCtr;
> void main(void)
> {
> char tmp;
> TRISB=0;
> degCtr=0;
> while(1)
> {
> tmp=255;
> while(tmp) tmp--;
> tmp=255;
> while(tmp) tmp--;
> degCtr++;
> LATB=degCtr;
> }
> }
> </CODE>
>
> On the 2550, that code glitches every ~7-8ms. I can change the values
> tmp is reloaded with and it does not change the glitch interval. Two
> different 2550's exhibit the same behavior (the third one I have would
> not program CONFIG bits properly, so I couldn't use it). However, 4550
> runs the same code, as expected, with PB7-PB0 cascading frequency
> outputs. The 2550 exhibits weird behavior, as though the degCtr is
> being reset or modified arbitrarily. There doesn't seem to be a
> pattern to the glitch other than the timing. WDT, BOR, STOVF, MCLR are
> disabled on both working and non working targets. I suppose it is
> possible that both 2550's are faulty but no real way to qualify that
> unless I order a few more.
>
> Yes I know the code is not optimally written.
>
> Appreciate all your collective patience with my debugging,
> 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
--
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 (List Account)]

Stupid questions, some of which may not be applicable to your part:

Which pins on PortB?

Have you unplugged the programmer, as port B is where the programmer lives?

Have you disabled LVD? Have you set reset to be an input instead of
~RESET~?

Are you sure the unit is not resetting? I.E. read the reset register, turn
on a pin whenever it resets for a few cycles. Are you sure the WDT isn't
enabled in the config words and you're getting WDT resets? Same with the
brownout protection, etc.

Are you sure that *all* of the peripherals which use the port b pins you're
interested in are disabled?


On Wed, Dec 20, 2017 at 11:14 PM, andrew kelley <***@gmail.com>
wrote:

> Well, I have tried the following to no avail:
>
> swapped the chip out for another one (18f2550, other target that
> worked was a 18f4550)
> swapped the crystal out (20mhz, tried adding caps to ground like DS
> recommends, no change)
> swapped out bypass capacitors
> swapped out Vusb capacitor
>
> with no changes in behavior. I'd hate to have to retarget to a 18f4550
> but I don't see what is wrong. It is not a complex circuit.. basically
> just the USB connection (powered from USB), USB cap, decoupling caps,
> a few resistors (not connected to anything right now), and a couple
> NPN drivers (also not connected right now). The circuit is built on
> vector board and a .6" chip won't quite fit nearly as well, due to the
> other stuff already on the board (mostly LEDs and resistors, intent is
> to simulate a engine and capture the injector & coil pulse width to
> aid in testing the PCM while developing code instead of risking an
> engine).. I could put the PIC on a separate board because it only has
> 8 lines tied to the ECU.. Probably not a bad idea anyway to help
> isolate the PCM from the PIC. Still it bothers me as to why the code
> runs fine on a 18f4550, but not a 18f2550. Not the target code mind
> you, but the simplest test code that reproduces the issue.
>
> <CODE>
> char degCtr;
> void main(void)
> {
> char tmp;
> TRISB=0;
> degCtr=0;
> while(1)
> {
> tmp=255;
> while(tmp) tmp--;
> tmp=255;
> while(tmp) tmp--;
> degCtr++;
> LATB=degCtr;
> }
> }
> </CODE>
>
> On the 2550, that code glitches every ~7-8ms. I can change the values
> tmp is reloaded with and it does not change the glitch interval. Two
> different 2550's exhibit the same behavior (the third one I have would
> not program CONFIG bits properly, so I couldn't use it). However, 4550
> runs the same code, as expected, with PB7-PB0 cascading frequency
> outputs. The 2550 exhibits weird behavior, as though the degCtr is
> being reset or modified arbitrarily. There doesn't seem to be a
> pattern to the glitch other than the timing. WDT, BOR, STOVF, MCLR are
> disabled on both working and non working targets. I suppose it is
> possible that both 2550's are faulty but no real way to qualify that
> unless I order a few more.
>
> Yes I know the code is not optimally written.
>
> Appreciate all your collective patience with my debugging,
> 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: [phone] | Address: 3577 Countryside Road, Helena, MT 59602
***@imach.com | http://www.packetflux.com
<http://www.linkedin.com/in/fwchristian> <http://facebook.com/packetflux>
<http://twitter.com/@packetflux>
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

Embedded below.

On Thursday, December 21, 2017, Forrest Christian (List Account) <
***@packetflux.com> wrote:

> Stupid questions, some of which may not be applicable to your part:
>
> Which pins on PortB?


Outputting to entire port. I may try to hook the LA to the entire port and
then I'll see exactly what's happening since I'll see the whole 8 bits of
degctr.


> Have you unplugged the programmer, as port B is where the programmer lives?


Usb bootloaded. Nothing attached to PB.

Have you disabled LVD? Have you set reset to be an input instead of
> ~RESET~?


Lvd disabled. Tried both ways on reset line.

Are you sure the unit is not resetting? I.E. read the reset register, turn
> on a pin whenever it resets for a few cycles. Are you sure the WDT isn't
> enabled in the config words and you're getting WDT resets? Same with the
> brownout protection, etc.


Checked and doubled checked config bits. Good idea on testing the reset
register. I'll do that along with capturing the whole port.


> Are you sure that *all* of the peripherals which use the port b pins you're
> interested in are disabled?


Not explicitly. (Except CCP, which is config'd to portc)

I'll see what I can figure out based on this.. it is entirely possible both
2550s are dysfunctional but for two processor to seem to reset at the same
interval is odd.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Brent Brown]

On 21 Dec 2017 at 1:14, andrew kelley wrote:

> <snip> Still it bothers
> me as to why the code runs fine on a 18f4550, but not a 18f2550. Not the
> target code mind you, but the simplest test code that reproduces the
> issue.
>
> <CODE>
> char degCtr;
> void main(void)
> {
> char tmp;
> TRISB=0;
> degCtr=0;
> while(1)
> {
> tmp=255;
> while(tmp) tmp--;
> tmp=255;
> while(tmp) tmp--;
> degCtr++;
> LATB=degCtr;
> }
> }
> </CODE>

I have in the past had problems with compiler supplied header files altering the
behaviour of the config macros, between chips and between compiler versions,
although in my case it was Hi-Tech/MicrochipXC8. With that in mind, and if not tried
already, I'd double check with and without WDT enabled, even change the WDT
period to see if it's related.

Not shown in your code above is disabling of interrupts. Perhaps the bootloader is
leaving something in an unexpected state.

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[andrew kelley]

I've checked the bootloader code, as well as read the config bytes out and
checked them that way. I'll try disabling interrupts explicitly. Wdt is
indeed disabled and the period set to the maximum.

Thanks, I'll post if I figure it out.

On Thursday, December 21, 2017, Brent Brown <***@eds.co.nz> wrote:

> On 21 Dec 2017 at 1:14, andrew kelley wrote:
>
> > <snip> Still it bothers
> > me as to why the code runs fine on a 18f4550, but not a 18f2550. Not the
> > target code mind you, but the simplest test code that reproduces the
> > issue.
> >
> > <CODE>
> > char degCtr;
> > void main(void)
> > {
> > char tmp;
> > TRISB=0;
> > degCtr=0;
> > while(1)
> > {
> > tmp=255;
> > while(tmp) tmp--;
> > tmp=255;
> > while(tmp) tmp--;
> > degCtr++;
> > LATB=degCtr;
> > }
> > }
> > </CODE>
>
> I have in the past had problems with compiler supplied header files
> altering the
> behaviour of the config macros, between chips and between compiler
> versions,
> although in my case it was Hi-Tech/MicrochipXC8. With that in mind, and if
> not tried
> already, I'd double check with and without WDT enabled, even change the WDT
> period to see if it's related.
>
> Not shown in your code above is disabling of interrupts. Perhaps the
> bootloader is
> leaving something in an unexpected state.
>
> --
> 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

[andrew kelley]

Checked reset flags, seems like a reset instruction is being executed, but
there isn't one in the code. I'm thinking both these 2550s are faulty,
considering the Exact Same Code runs perfect on one of my 4550 boards. I
haven't any idea why it would be that way, but it is what it is and that's
all it is.

Thanks for the help
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

[Brent Brown]

The chance of 2 chips being faulty seems kind of low, so possibily still some other issue. Could still be in the config bits... programmed at the time the bootloader is loaded and can't be changed thereafter (pretty sure PIC can't self write config bits). You can probably read those back with a programmer, but if the config bits aren't right the programmer itself becomes a suspect.
Good that flags show a reset is happening (which almost certainly explains the symptoms). You can probably go further and deduce if it was from WDT reset or something else. On the other hand, your "it is what is" comment could indicate you're ready to move on. Understood. Less than 12hrs to Christmas here~!

-------- Original message --------
From: andrew kelley <***@gmail.com>
Date: 12/23/17 5:07 PM (GMT+12:00)
To: "Microcontroller discussion list - Public." <***@mit.edu>
Subject: Re: [PIC]: 18f2550 timer 1 interrupt glitch?

Checked reset flags, seems like a reset instruction is being executed, but
there isn't one in the code. I'm thinking both these 2550s are faulty,
considering the Exact Same Code runs perfect on one of my 4550 boards. I
haven't any idea why it would be that way, but it is what it is and that's
all it is.

Thanks for the help
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
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gál Zsolt]

Hello Andrew,

Are these codes in a same program? My opinion is that silicon errata writes
different solution for the "Special considerations for interrupt context
save" problem on the page 6.

http://ww1.microchip.com/downloads/en/DeviceDoc/80478a.pdf

Regards,

Zsolt

<CODE>
char degCtr;
void main(void)
{
char tmp;
TRISB=0;
degCtr=0;
while(1)
{
tmp=255;
while(tmp) tmp--;
tmp=255;
while(tmp) tmp--;
degCtr++;
LATB=degCtr;
}
}
</CODE>

-------------------------------------------------

void HighPriorityISRCode()
{
//A3 silicon errata
_asm pop _endasm

if(PIR1bits.TMR1IF)
{
T1CONbits.TMR1ON=0;
WriteTimer1(degTmrCt);
PIR1bits.TMR1IF=0;
degCtr++;
degTDC++;
PIR1bits.TMR1IF=0;
switch(degCtr)
{
case(28):
case(48):
case(68):
case(88):
LATB &= CKP_ON;
break;
case(30):
case(50):
case(70):
case(90):
LATB |= CKP_OFF;
break;
case(120):
degCtr=0;
cmpCtr--;
if(cmpCtr==0)
{
LATB ^= CMP_SIG;
cmpCtr=3;
}
break;
}
if(degTDC==60)
degTDC=-60;

-----------------------------------------

2017-12-19 7:52 GMT+01:00 andrew kelley <***@gmail.com>:

> 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 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
>



--
~~~~~~~~~~~~~~~~
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist