I'm trying to write a serial transfer host on a PIC16F877 that uses two interrupt sources: TMR0 and RB0/INT. The code appears to work fine at first, but after a while, I get a change on a pin that is not only unexpected, but has moderately disatarous consequences (i.e. aborts a transfer and the rest never recovers)
What I'm wondering is if there is any way that I can extract the top value from the stack to read it, not return to it.
When I simulate the software, it looks like it should be fine, but when I actually come to running it, there's that problem. I think the reason it simulates fine is that there is no reasonable way to simulate the remote device that the host is communicating with.
So, any ideas on how to determine whre in my code I am when I get this error?
Well, I haven't recieved any responses, but I got around the problem. Looks
like my clock speed wasn't high enough, so I was getting interrupts on top
of interrupts.
I'm still interested in whether it's possible to debug a problem that
requires finding where you are in your code without using an ICE.
> I'm still interested in whether it's possible to debug a problem that
> requires finding where you are in your code without using an ICE.
Usually what I do is to set and extra output high depending on the
situation. Depending on the situation you can just lit a LED to see that you
are past some part of the program. It all depends on the resources you have
available. With an Scope you can drive a certain pattern to see where you
are. With a logic analyser you can send full bytes out. With an LED you can
see that you are past some point. Debugging is always the hardest part of
most programs. I almost never use a logic analyser or an ICE, they take too
much time to setup, but I do flash led's a lot when I am writing programs. A
piezo sounder is also a nice option to have around. Basically you want to
use the "external World" interfaces that you have around your CPU.
> I'm still interested in whether it's possible to debug a problem
> that requires finding where you are in your code without using
> an ICE.
Like probably most people here I use a pin or LED as an
indicator. Dot a few around the s/w, add a few conditional
branches if necessary, and you can get a fair idea of which
section of code is being executed
I think you have appreciate correct your problem. Could be a stack false
jump. I'll do it in a different way without too much simulation: split
your interrupt code in two, tmr0 related and int/rb0 related. Check if
both are going fine with your usart. If yes then :
-- check if you save and restore corectly all your registers
-- check if you deactivate the interrupt while you run specific interrupt
serviceing code
-- check the main code again, it could be a place which required to
deactivate the interrupts, maybe in the serial routine ?
> I'm trying to write a serial transfer host on a PIC16F877 that uses two interrupt sources: TMR0 and RB0/INT. The code appears to work fine at first, but after a while, I get a change on a pin that is not only unexpected, but has moderately disatarous consequences (i.e. aborts a transfer and the rest never recovers)
>
> What I'm wondering is if there is any way that I can extract the top value from the stack to read it, not return to it.
>
> When I simulate the software, it looks like it should be fine, but when I actually come to running it, there's that problem. I think the reason it simulates fine is that there is no reasonable way to simulate the remote device that the host is communicating with.
>
> So, any ideas on how to determine whre in my code I am when I get this error?
>
> --Brendan
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways. See http://www.piclist.com/#archives for details.
>
>
> I'm still interested in whether it's possible to debug a problem that
> requires finding where you are in your code without using an ICE.
As others have noted, one or more output lines that are set reset are MOST
useful.
Use of an oscilloscope can help. If a line is set on entry to the interrupt
routine and cleared on exit this will give you "interrupt occupancy"
percentage viewable on the scope. If the interrupt code is able to exceed
time available under some conditions, being able to see this is invaluable.
Setting and resetting a bit with a different delay from different places
will give you different pulse widths which MIGHT be able to be interpreted
on a scope. Eg one routine may set_bit, clear_bit while another adds 1 or
more instruction(s) between the set and clear. This is more likely to be
useful if there are several possible paths and you want to know which is
being taken.
Having a "heartbeat" pulse from the IRQ routine can help in syncronising
plus provide time in IRQ routine as well as above. .
Getting a little fancier but still without a logic analyser one can use
several lines and drive a suitably fast D2A (possibly just a few resistors)
so that the analog level varies depending on what code was last written to
the port. An extreme version of this i heard of log ago created two A2D's
and plotted them against each other on an X/Y scope display. You can then
see occupancy in each area in code (based on brightness of spot in each area
and whether a particular routine is getting called at all or not.
Depending on the speed of processing and interrupt rate etc you MAY be able
to implement a fast serial output stream with routines providing a code to
be sent out in serial. Speed is liable to be too slow for many real
applications.
Depends how many pins you have empty. As Jinx said use LED's. Do you
have two free pins? If so build a simple program that when your
communication is aborted a clock kicks in and displays the address on
the two led's (one led is the clock and one is data). Make the pulses a
second long or so as to be readble to a human. :)
Toggling select output pins is a life-saver on
as integrated a simple SOC (Systen On a Chip)
that the PIC is -
- in the 'old days' it was easy to setup a logic
analyzer to 'trigger' a scope in conjunction with
a harware pin that was set to toggle at a specific
point on code and accurate and meaningful timing
measurements of 'code execution speed' could be
made by triggering the logic analyzer around through
various addresses in the code ...
I have also set up various *special* addresses in RAM
written to by code for the analyzer to grab and display
for me to 'read' - different addresses in RAM would be
set to inspect certain data streams for instance ...
Something similar with a PIC could be done with a spare
or 'free' I/O port and a logic analyzer or a simple set
of shift registers - but by using a logic analyzer and
recognizing certain patterns written to the port timing
measurements could be done throughout code as well (WITH
the cooperation of the code - by writing a special unique
patterns to the port inconjunction with a separate harware
I/O pin toggle!).
Lacking that (and an ICE) - LED's and a scope tied to a
toggling pin are the way to go.
> Having a "heartbeat" pulse from the IRQ routine can help in syncronising
> plus provide time in IRQ routine as well as above. .
If I had done that in the first place, it would have saved me tons of
trouble. It turns out that the PIC, which was running at 2MHz at the time,
was operating just a bit (sorry about that pun) too slow. It was losing an
edge that it needed to process, so it was messing up the following
transmission. I increased the clockrate to something near 3.6MHz, and I'm
not having the problem anymore.
The way I figured that out, however, is slightly different. I looked at the
time it had to porcess a single request, which turned out to be 22 cycles at
the speed I was running, which isn't enough for the code I'm using. (takes
time to do context saving, which is a must in an interrupt driven system)
But, in my opinion, 22 cycles is more than enough to read a single bit in
off of a synchronous port, so I'm considering switching from the interrupt
driven code to continuous polling. That way it takes a max of 5 cycles to
finish responding to an edge (little more if you want to do inline parity
checking).
I've never liked the interrupt system. I want an event based MCU!! Like
that's going to happen any time soon... *sigh*
> I've never liked the interrupt system. I want an event based MCU!! Like
> that's going to happen any time soon... *sigh*
Nothing prevents you from looking at the interrupt flag bits with the
interrupts disabled. Polled event versus interrupt is only a matter of
firmware choice.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
> Nothing prevents you from looking at the interrupt flag bits with the
> interrupts disabled. Polled event versus interrupt is only a matter of
> firmware choice.
While this is true, a truly event based processor would have 2 cores: 1
event core and one processing core. The processing core would remain idle
until the event core called it, and this is where it differs from polling,
the event core would be able to interrupt with an event of higher priority
if neccessary. (And I think processors should have built in context saving
too....) Real-time processing... Yay... interrupting interrupts. A of
course that's only practical in an app where the processor has a stack
that's a bit deeper than 8 levels.
> While this is true, a truly event based processor would have 2 cores: 1
> event core and one processing core. The processing core would remain idle
> until the event core called it, and this is where it differs from polling,
> the event core would be able to interrupt with an event of higher priority
> if neccessary. (And I think processors should have built in context
saving
> too....) Real-time processing... Yay... interrupting interrupts. A of
> course that's only practical in an app where the processor has a stack
> that's a bit deeper than 8 levels.
What you are describing sounds more like a multi-priority interrupt system
than an event polling system. Note that the 18 family PICs do have two
interrupt priority levels, so a high priority interrupt can be serviced in
the middle of servicing a low priority interrupt.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
mitvma.mit.edu with SET PICList DIGEST in the body
